Классическая шпаргалка по логическому порядку выполнения SQL-запроса

Угадайте песню 😉

Как IBM упустила миллиарды, или История создания SQL
Давайте немного отвлечемся от кода и заглянем в историю.
Вы возможно часто пишете команды SELECT и WHERE, но знаете ли вы, что язык SQL появился благодаря одной научной статье и... грандиозной ошибке гиганта IBM?
Как всё начиналось?В 1970 году математик из IBM Эдгар Кодд придумал революционную идею — реляционные базы данных (хранение данных в виде связанных таблиц). До этого данные хранились в виде хаотичных «деревьев», и чтобы достать нужную строчку, программистам приходилось писать сложнейший код.
Кодд предложил сделать язык, который будет похож на обычный английский, чтобы менеджеры могли сами писать запросы без помощи программистов. Так в лабораториях IBM родился язык SEQUEL (позже сокращенный до SQL).
Ошибка на миллиарды долларов - руководство IBM в те годы зарабатывало на продаже огромных мейнфреймов (суперкомпьютеров) и посчитало реляционные базы данных просто «игрушкой для ученых». Они опубликовали описание языка SQL в открытых научных журналах, не придав этому значения.
Рождение конкурента - эту статью прочитал молодой и амбициозный инженер Ларри Эллисон. Он мгновенно понял(и не ошибся), что за табличными базами данных — будущее. Ларри с друзьями взял открытые наработки IBM и всего за несколько месяцев написал свою коммерческую базу данных, использующую язык SQL.
Они назвали свою компанию Oracle.Когда в IBM наконец опомнились и выпустили свою систему (DB2), Oracle уже захватила рынок.
Ларри Эллисон стал одним из богатейших людей планеты(красавчег)) ), а SQL — мировым стандартом, который мы с вами учим сегодня.

CHAR против VARCHAR: В чем разница?
Когда мы создаем таблицу и хотим сохранить туда текст (например, имя пользователя или страну), перед нами всегда встает выбор: какой тип данных выбрать — CHAR или VARCHAR? Оба типа хранят строки, но делают это совершенно по-разному.

CHAR (Фиксированная длина)Если вы укажете CHAR(10), MySQL всегда будет выделять ровно 10 байт под эту ячейку.Если вы запишете туда слово из 5 букв (например, «Hello» — 5 буквы), база данных автоматически допишет в конец 5 пробелов, чтобы забить место.
Где применять: Для данных, длина которых никогда не меняется. Например: код страны (RU, US), серия паспорта или хэш-пароли (MD5 всегда 32 символа).

VARCHAR (Переменная длина)Если вы укажете VARCHAR(10) и запишете слово «Hello», база данных потратит ровно 5 байта (плюс 1 байт на хранение длины строки). Никаких лишних пробелов!
Где применять: Для данных, длина которых заранее неизвестна. Например: email, фамилия, текст комментария.

Главное правило для шпаргалки: Знаете точную длину? Используйте CHAR (он работает чуть быстрее).Длина может меняться? Используйте VARCHAR (он экономит кучу места на диске).

Сегодня экономим байт на записи, завтра терабайт на таблице

Время анекдота)
Парень-SQLщик на первом свидании говорит девушке:
— Ты для меня как тип данных CHAR(100).
— Ой, как мило! Это потому, что я занимаю много места в твоем сердце?
— Нет, просто сколько бы ты ни говорила, ты всегда забиваешь оставшуюся память кучей лишних пробелов.

Задачка на прокачку SQL: Опасные пробелы
Представьте, что мы создали таблицу users и добавили туда одну строку. Тип данных столбца username — VARCHAR(20).

В базе лежит одна запись:
id: 1, username: 'Alex' (обратите внимание: в конце имени нет пробелов).

Мы выполняем следующий запрос на поиск пользователя:
SELECT * FROM users WHERE username = 'Alex ';
(В строке поиска после имени 'Alex' идет 3 пробела).

Вопрос: Сколько строк вернет этот запрос в MySQL?
A. 1 cтрока (найдет пользователя 'Alex')
Б. 0 строк (ничего не найдет, ведь пробелы имеют значение)
Г. Будет ошибка синтаксиса (Error)

Правильный ответ и детальный разбор, почему MySQL ведет себя именно так, будет через пару дней. Пишите свои логические обоснования в комментарии

Задачка на прокачку SQL: разбор ответа про пробелы
Правильный ответ: 1 строка :)
Запрос успешно найдет пользователя 'Alex', несмотря на лишние пробелы в условии.
В чем подвох и почему и как это работает? Все дело в стандарте ANSI SQL и том, как MySQL обрабатывает сравнение строк.
Правило Pad Space: По умолчанию в MySQL при сравнении строк оператором = (равно) используется алгоритм, который игнорирует конечные пробелы (trailing spaces).
СУБД виртуально «добивает» короткую строку пробелами до длины длинной строки, а затем уже сравнивает их.
Поэтому 'Alex' и 'Alex ' для нее это одно и то же.
Исключение из правил - это поведение справедливо для большинства кодировок (Collations) и типов данных (CHAR, VARCHAR).
Однако, если вы будете использовать оператор LIKE вместо =, магия исчезнет:
WHERE username LIKE 'Alex '
вернет 0 строк, так как LIKE учитывает каждый символ буквально.

Как это исправить, если вам нужно строгое сравнение?
Если логика вашего приложения требует учитывать пробелы, например, при авторизации или поиске, есть два варианта:
1. Использовать оператор LIKE

2. Привести строку к бинарному виду с помощью BINARY:
SELECT * FROM users WHERE BINARY username = 'Alex ';
В таком случае MySQL будет сравнивать байты символов напрямую, и запрос вернет 0 строк.

Кстати, с прошедшим 256-м днем года ;)

История о Git.
Сегодня Git — это абсолютный стандарт. Но знаете ли вы, что Git появился не из-за планового расширения технологий, а в результате скандала?

2005 год, проблема эпического масштаба: Линус Торвальдс уже более 10 лет развивает операционную систему Linux. Проект стал огромным, над ним бесплатно работают тысячи программистов со всего мира.
И... они увязают в хаосе. Чтобы объединить код от разных людей, Линус принимает патчи по обычной электронной почте и накладывает их вручную!(наверное это был ад )).

Тогда коммерческая компания BitMover предлагает Linux-сообществу спасение — бесплатно использовать их крутую систему контроля версий BitKeeper. Но с одним жестким условием: код BitKeeper нельзя изучать, реверс-инжинирить и создавать на его основе аналоги. Линус соглашается, и дела идут в гору.

Немного позже из ключевых разработчиков Linux, Эндрю Триджелл (кстати, создатель знаменитой Samba), решает автоматизировать свою рутину. Ему надоело вручную выкачивать данные, и он пишет простенький скрипт, который подключается к серверам BitKeeper.

Глава BitMover узнает об этом и приходит в ярость: «Вы нарушили лицензию! Вы пытаетесь украсть наши технологии!». В наказание он отзывает бесплатную лицензию у всего сообщества Linux.Проект стоимостью в миллиарды долларов в один день остается без системы управления кодом. Паника. Кризис. Разработчики винят Эндрю, Эндрю оправдывается.
Линус Торвальдс не был бы собой, если бы пошел на поклон. Он объявляет бойкот BitKeeper, закрывается в своей комнате и ставит цель: написать свою систему контроля версий. Линусу нужна была система, которая сможет обрабатывать гигантский код Linux за доли секунды.

Линус начал писать код 3 апреля 2005 года.
Через 4 дня система уже могла записывать изменения в файлы.
Через 10 дней Линус совершил первый в истории Git-коммит самого кода Git.
Через 2 недели Линус представил миру рабочую версию системы.Он назвал её Git.
Так BitKeeper стал никому не нужен, а Git завоевал планету, изменив мир разработки навсегда.

Продолжим про Git )) Как называется главный указатель в Git, который всегда «смотрит» на вашу текущую активную ветку?
A. MASTER
B. USER
C. GIT
D. HEAD
Правильный ответ через пару дней

Продолжим про Git :)
Какая команда добавит файл products.html в индекс (staging area) для подготовки к последующему коммиту?
1. git register products.html
2. git stage products.html
3. git commit products.html
4. git push products.html
5. git add products.html

Официальный талисман — дельфин Сакила.
У MySQL есть узнаваемый логотип с дельфином. Его зовут Сакила (Sakila).
Это имя было выбрано по результатам конкурса среди пользователей и разработчиков.
Имя имеет африканские корни и на языке свати означает «прыгать из воды».
Кстати, это же имя носит стандартная тестовая база данных, которую разработчики используют для примеров и обучения.

Какая из характеристик функции в MySQL предполагает, что функция будет возвращать одинаковый результат для одних и тех же входных значений?
1 MODIFIES SQL DATA
2 DETERMINISTIC
3 READS SQL DATA
4 CONTAINS SQL

Сегодня и завтра участвуем в конференции Stepicon, оффлайн в Москве.
Учимся учить любимых студентов =)

Новая задача: есть две таблицы, authors и books, соединенные по внешнему ключу.
Если вы выполняете LEFT JOIN из таблицы authors в таблицу books, что произойдет с автором, который написал ноль книг?

A. Автор будет включен в результат, а для всех колонок из таблицы books будут проставлены значения NULL.
B. Автор будет полностью исключен из результирующего набора, что аналогично поведению INNER JOIN.
C. База данных сгенерирует ошибку нарушения ссылочной целостности (constraint violation).
D. Информация об авторе будет дублироваться до тех пор, пока система не сгенерирует искусственный ID книги.

Попросили ответы объяснять. Пробуем )
A. Автор будет включен в результат, а для всех колонок из таблицы books будут проставлены значения NULL.
Это верный ответ! LEFT JOIN гарантирует сохранение всех записей из левой таблицы (authors), подставляя NULL для полей правой таблицы при отсутствии совпадений.

B. Автор будет полностью исключен из результирующего набора, что аналогично поведению INNER JOIN.
Неправильно. Исключение строк без соответствий характерно для INNER JOIN, в то время как LEFT JOIN сохраняет левую сторону целиком.

C. База данных сгенерирует ошибку нарушения ссылочной целостности (constraint violation).
Неправильно. Использование LEFT JOIN — это штатная операция выборки, которая не вызывает ошибок ограничения целостности, даже если связей нет.

D. Информация об авторе будет дублироваться до тех пор, пока система не сгенерирует искусственный ID книги.
Неправильно. Дублирование строк возникает при наличии нескольких совпадений в правой таблице, а не тогда, когда их количество равно нулю.