Раздел 1 — Базы данных в разработке ПО

Любое приложение сложнее калькулятора должно что-то помнить между запусками: пользователей, заказы, сообщения, настройки. Оперативная память для этого не годится — она очищается при перезапуске процесса. Данные должны пережить и перезапуск приложения, и перезагрузку сервера.

Типичное веб-приложение делится на три слоя:

Слой представления и логика — код, который вы переписываете часто. База данных живёт дольше кода: приложение перепишут с PHP на Go, а таблица users останется та же. Поэтому ошибка в схеме БД стоит дороже ошибки в контроллере — её исправление затрагивает уже накопленные данные.

Разделим два понятия, которые в речи путают:

PostgreSQL, MySQL, Oracle — это СУБД. «Социальная сеть», которую вы будете изучать в этом курсе, — база данных, работающая под управлением PostgreSQL.

Данные можно хранить в обычных файлах — CSV, JSON, XML. Так делали до появления СУБД, и так до сих пор делают в мелких задачах. Проблемы начинаются на масштабе.

Представьте магазин, который хранит заказы в orders.csv, а клиентов — в clients.csv. Пять типовых бед:

К этому добавляются задачи, которые в файловом подходе даже не ставятся: как откатить наполовину выполненную операцию, как дать бухгалтеру доступ к суммам, но не к паролям, как восстановить состояние на вчерашний вечер.

СУБД берёт на себя всё перечисленное. Её функции:

Приложение обращается к СУБД по сети — это отдельный процесс, часто на отдельной машине. Такая схема называется клиент-серверной: сервер СУБД принимает соединения, клиенты (ваше приложение, DBeaver, psql) отправляют запросы и получают результат.

Модель данных — способ, которым СУБД представляет информацию. От модели зависит, какие задачи решаются легко, а какие — с трудом.

Все нереляционные модели объединяют собирательным словом NoSQL. Название неудачное: оно говорит, чего в них нет, а не что в них есть. Общего между Redis и Neo4j — примерно ничего.

Реляционная модель остаётся выбором по умолчанию для большинства приложений: она даёт целостность, транзакции и зрелый язык запросов. Именно поэтому основная СУБД курса — PostgreSQL. Сравнению СУБД между собой посвящён раздел 12.

Базы данных решают две принципиально разные задачи, и путать их дорого.

Опасность в том, что тяжёлый аналитический запрос, запущенный на боевой базе приложения, забирает ресурсы у пользовательских операций — сайт начинает тормозить. Поэтому аналитику выносят: на реплику базы, в отдельное хранилище или в колоночную СУБД.

Стандарт ANSI/SPARC описывает базу данных на трёх уровнях. Эта абстракция объясняет, почему СУБД вообще устроены так, а не иначе.

Разделение уровней даёт два свойства, ради которых всё и затевалось:

Классический пример: перевод денег между счетами. Это две операции — списать у одного, зачислить другому. Если между ними сервер выключится, деньги исчезнут.

Транзакция — группа операций, которая выполняется как единое целое. Либо все операции применены, либо ни одна. Свойства транзакций описывают аббревиатурой ACID:

Пока достаточно знать, что это такое и зачем. Подробно — уровни изоляции, аномалии параллельного доступа, взаимные блокировки — в разделе 11.

Выбор СУБД в российской компании — не только техническое решение. С 2022 года иностранные вендоры ушли: Oracle, Microsoft и SAP не продают лицензии и не оказывают поддержку. Для государственных организаций и компаний с госучастием действует требование использовать ПО из реестра отечественного ПО Минцифры.

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

Курс рассчитан на первую роль, но захватывает вторую: разработчик, который не умеет поднять и настроить PostgreSQL, беспомощен без администратора.