Приветствуем вас, выпускники Stepik! Рады видеть каждого на этом канале!

Вы здесь, потому что сделали важный шаг — успешно прошли курсы и получили новые знания.
Кто-то из вас только начинает свой путь в IT с нуля, а кто-то — зашел обновить и структурировать уже имеющуюся базу.
В любом случае — вы большие молодцы!

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

Давайте познакомимся в комментариях! Нам очень важна обратная связь, чтобы делать контент полезным именно для вас:
1 Какую цель вы перед собой ставите? Учитесь с нуля на новую профессию или обновляете знания для текущей работы?
2 Что вызвало наибольшие трудности на курсе? Какая тема или задача показалась самой сложной?
3 В какие темы вы бы хотели углубиться сильнее? Чего вам не хватило в рамках стандартной программы?

Поделитесь своим мнением — именно на основе ваших ответов мы будем строить следующие публикации, разборы задач и полезные шпаргалки.
Добро пожаловать, и давайте расти вместе!

Задачка на прокачку SQL:

Есть таблица сотрудников employees, и в ней всего 3 строки, в столбце commission (комиссионные) хранятся следующие значения:
+--+------------+-------------------+
|id|name |commission|
+--+------------+-------------------+
|1 |Илья |100 |
|2 |Анна |0 |
|3 |Максим|NULL |
+--+------------+-------------------+

Мы выполняем следующий запрос:
SELECT * FROM employees WHERE commission != 100;

Вопрос: Сколько строк вернет этот запрос?
Правильный ответ опубликуем через пару дней.

Задачка на прокачку SQL: разбор ответа
Правильный ответ: 1 строка (в результат попадет только Анна).
Разбор по строкам:
Илья (commission = 100): Условие 100 != 100 ложно (FALSE). Строка отсеивается.
Анна (commission = 0): Условие 0 != 100 истинно (TRUE). Строка попадает в выборку.
Максим (commission = NULL): Строка отсеивается.

Почему? В чем подвох? Вся хитрость заключается в том, как SQL работает с NULL.
Это фундаментальное правило реляционных баз данных и стандарта ANSI SQL.
В SQL используется трехзначная логика (Three-Valued Logic или 3VL).
Это значит, что логическое выражение может принимать не два, а три значения:TRUE (Истина), FALSE (Ложь), UNKNOWN (Неизвестно).

NULL — это не ноль и не пустая строка. Это неизвестность (отсутствие данных).
Когда СУБД пытается сравнить NULL != 100, она «рассуждает» так: «Я не знаю, чему равна комиссия Максима. Равна ли неизвестность числу 100? Я не могу сказать ни да, ни нет». Поэтому любое сравнение с NULL (будь то =, !=, < или >) всегда возвращает UNKNOWN.
Так как оператор WHERE фильтрует данные и пропускает дальше только те строки, которые получили строго TRUE, Максим в итоговую выборку не попадает.

Как это исправить?Если бы вам нужно было найти всех, у кого комиссия не равна 100, и например, включая тех, у кого она не заполнена, запрос пришлось бы переписать с явной проверкой:
SELECT * FROM employees WHERE commission != 100 OR commission IS NULL;

Классическая шпаргалка по логическому порядку выполнения 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).
Это имя было выбрано по результатам конкурса среди пользователей и разработчиков.
Имя имеет африканские корни и на языке свати означает «прыгать из воды».
Кстати, это же имя носит стандартная тестовая база данных, которую разработчики используют для примеров и обучения.