Задачка на прокачку 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 книги.
Неправильно. Дублирование строк возникает при наличии нескольких совпадений в правой таблице, а не тогда, когда их количество равно нулю.