Базы данных и SQL
Кому это нужно? - Разработчикам (любым, в особенности бэкенду), а также всем, кто работает с данными: аналитикам, дата-саентистам.
Сама я изучала базы данных на стэнфордском курсе - вот его современная версия - он бесплатный, на английском языке.
Ниже я набросала чек-лист, что нужно (или желательно) изучить для работы с базами данных. Порядок пунктов можно менять, я постаралась отсортировать от простого к сложному. Если овладеть всем списком - это будет уровень выше Junior-разработчика, так что не пугайтесь объёма, всё нарабатывается постепенно.
0. (Необязательно) Реляционная алгебра - это несложный раздел математики, он даёт представление о том, как устроены базы данных - что такое реляционная модель и какие операции над ней можно проводить. Это то же, что вы будете делать с помощью SQL, но на абстрактном математическом языке.
1. SQL: простые SELECT-запросы для получения данных из таблицы.
2. Простые запросы для добавления строк в таблицу: INSERT.
3. Запросы для изменения данных: UPDATE и DELETE - но лучше сразу привыкайте делать их внутри транзакции (с ключевым словом BEGIN), чтобы в случае ошибки можно было откатить изменения. А то потом на работе удалите важные данные и будет не прикольно.
4. Как создавать таблицы: CREATE-запросы. (а также изменять схему: ALTER).
5. Сложные запросы: как извлекать данные сразу из нескольких связанных таблиц: разные виды JOIN и для чего они нужны.
6. Индексы. Когда нужно найти данные в таблице, где хрянятся миллионы строк, это может занять очень много времени. Но если создать правильные индексы, мы подскажем базе данных, как быстро найти данные, и работать всё будет быстро. Так что нужно научиться - а) определять, где нужны индексы и создавать их и б) писать SELECT-запросы так, чтобы эти индексы использовались.
7. Оптимизация запросов: вот вы научились извлекать данные из нескольких таблиц со множеством сложных условий. Но загвоздка в том, что одни и те же данные можно получить разными способами, и не все способы одинаково хороши. Можно написать такой запрос, что он не выполнится и за 100 лет. Плохой запрос может вывести из строя (на время) базу данных и сломать ваш проект (например, сайт). Поэтому разработчику мало уметь написать запрос как-то, нужно еще найти оптимальный способ. Для анализа эффективности запросов есть команды EXPLAIN и EXPLAIN ANALYZE - с их помощью можно проверить разные запросы и подобрать лучший. Например, избегать запросов, которые приводят к операции full scan(она же seq scan) - это когда базе данных нужно просканировать ВСЕ строки в таблице (если таблица большая, это займёт очень много времени, если маленькая - пофиг).
8. Транзакции. Представьте, что вы перевели деньги другу, у вас со счета деньги списались, а на его счету не появились - это пример неправильной работы с транзакциями. Или же, например, у вас на счету 500 рублей, вы снимаете их в банкомате, банковская система обновляет ваш счет, чтобы выставить там значение 0 - но ровно в ту же секунду вам приходит зарплата. Зарплата поступает на счет, но затем выполняется операция по «обнулению» счёта - и у вас на счету ноль. Описанных ситуаций не должно происходить, но они могут случиться, если разработчики неграмотно используют транзакции (или не используют их вовсе). В первом случае, когда деньги списались у вас, но не пришли другу из-за какого-то технического сбоя - вся транзакция должна была отмениться - другу деньги не пришли, значит отменяем операцию списания у вас. Во втором случае операция «приход зарплаты» не должна была «вклиниваться» перед операцией по списанию денег со счёта - она должна была подождать, пока завершится транзакция со списанием 500 рублей, а потом уже зачислить на счет зарплату.
9. Конкретные СУБД - у каждой системы управления базами данных (MySql, PostreSQL, Oracle, SQL Server) есть свои фишечки и особенности работы и особенности внутренней архитектуры - новичку об этом в начале можно не беспокоиться. Но когда вы устроитесь на работу, придётся разбираться с особенностями той СУБД, которую использует работодатель.
Кому это нужно? - Разработчикам (любым, в особенности бэкенду), а также всем, кто работает с данными: аналитикам, дата-саентистам.
Сама я изучала базы данных на стэнфордском курсе - вот его современная версия - он бесплатный, на английском языке.
Ниже я набросала чек-лист, что нужно (или желательно) изучить для работы с базами данных. Порядок пунктов можно менять, я постаралась отсортировать от простого к сложному. Если овладеть всем списком - это будет уровень выше Junior-разработчика, так что не пугайтесь объёма, всё нарабатывается постепенно.
0. (Необязательно) Реляционная алгебра - это несложный раздел математики, он даёт представление о том, как устроены базы данных - что такое реляционная модель и какие операции над ней можно проводить. Это то же, что вы будете делать с помощью SQL, но на абстрактном математическом языке.
1. SQL: простые SELECT-запросы для получения данных из таблицы.
2. Простые запросы для добавления строк в таблицу: INSERT.
3. Запросы для изменения данных: UPDATE и DELETE - но лучше сразу привыкайте делать их внутри транзакции (с ключевым словом BEGIN), чтобы в случае ошибки можно было откатить изменения. А то потом на работе удалите важные данные и будет не прикольно.
4. Как создавать таблицы: CREATE-запросы. (а также изменять схему: ALTER).
5. Сложные запросы: как извлекать данные сразу из нескольких связанных таблиц: разные виды JOIN и для чего они нужны.
6. Индексы. Когда нужно найти данные в таблице, где хрянятся миллионы строк, это может занять очень много времени. Но если создать правильные индексы, мы подскажем базе данных, как быстро найти данные, и работать всё будет быстро. Так что нужно научиться - а) определять, где нужны индексы и создавать их и б) писать SELECT-запросы так, чтобы эти индексы использовались.
7. Оптимизация запросов: вот вы научились извлекать данные из нескольких таблиц со множеством сложных условий. Но загвоздка в том, что одни и те же данные можно получить разными способами, и не все способы одинаково хороши. Можно написать такой запрос, что он не выполнится и за 100 лет. Плохой запрос может вывести из строя (на время) базу данных и сломать ваш проект (например, сайт). Поэтому разработчику мало уметь написать запрос как-то, нужно еще найти оптимальный способ. Для анализа эффективности запросов есть команды EXPLAIN и EXPLAIN ANALYZE - с их помощью можно проверить разные запросы и подобрать лучший. Например, избегать запросов, которые приводят к операции full scan(она же seq scan) - это когда базе данных нужно просканировать ВСЕ строки в таблице (если таблица большая, это займёт очень много времени, если маленькая - пофиг).
8. Транзакции. Представьте, что вы перевели деньги другу, у вас со счета деньги списались, а на его счету не появились - это пример неправильной работы с транзакциями. Или же, например, у вас на счету 500 рублей, вы снимаете их в банкомате, банковская система обновляет ваш счет, чтобы выставить там значение 0 - но ровно в ту же секунду вам приходит зарплата. Зарплата поступает на счет, но затем выполняется операция по «обнулению» счёта - и у вас на счету ноль. Описанных ситуаций не должно происходить, но они могут случиться, если разработчики неграмотно используют транзакции (или не используют их вовсе). В первом случае, когда деньги списались у вас, но не пришли другу из-за какого-то технического сбоя - вся транзакция должна была отмениться - другу деньги не пришли, значит отменяем операцию списания у вас. Во втором случае операция «приход зарплаты» не должна была «вклиниваться» перед операцией по списанию денег со счёта - она должна была подождать, пока завершится транзакция со списанием 500 рублей, а потом уже зачислить на счет зарплату.
9. Конкретные СУБД - у каждой системы управления базами данных (MySql, PostreSQL, Oracle, SQL Server) есть свои фишечки и особенности работы и особенности внутренней архитектуры - новичку об этом в начале можно не беспокоиться. Но когда вы устроитесь на работу, придётся разбираться с особенностями той СУБД, которую использует работодатель.