Базы данных: что это, где применяется и как освоить

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

Что входит в навык и чем он отличается от SQL

В отдельной статье сайта об SQL речь о том, как задать базе вопрос и не получить правдоподобный неверный ответ. Здесь — о том, как устроить базу, чтобы вопросы к ней имели смысл: какие сущности хранить (клиент, товар, заказ) и как их связать, какой тип и какие правила дать каждому столбцу, где нужен индекс, как часто делать копию и где её хранить.

От профессии администратора баз данных, о которой на сайте тоже есть статья, навык отличается масштабом: DBA держит рабочие серверы — реплики, обновления версий, дежурства.

Иногда база не нужна: список из пары сотен позиций, который ведёт один человек, удобнее держать в Excel или Google Таблицах. Переходить на СУБД стоит, когда записи правят несколько человек одновременно, данные связаны между собой (один клиент — много заказов) или ошибка в одной ячейке стоит денег.

Кому и зачем нужен навык

Backend-разработчик проектирует схему под новую функцию, пишет миграции (скрипты, которые меняют структуру таблиц без потери данных) и выбирает индексы. Ошибка в схеме проявится, когда таблица вырастет до миллионов строк.

Аналитик читает схему чужой базы, видит, где связь «один ко многим» размножит строки при соединении, и просит таблицу для отчётов, а не нагружает рабочую базу тяжёлыми запросами.

Владелец интернет-магазина редко сам создаёт таблицы: их заложила CMS. Но он решает, у кого есть доступ к данным о клиентах и есть ли свежая копия, из которой можно восстановиться. Требования к защите сведений о покупателях разобраны в статье сайта о защите персональных данных.

Специалист 1С работает через платформу, которая сама создаёт таблицы, но ему нужно понимать, чем файловый вариант базы отличается от клиент-серверного на PostgreSQL или Microsoft SQL Server и как регулярно выгружать и проверять копию информационной базы.

Учебный пример: база заказов небольшого магазина

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

Решение — нормализация: данные раскладывают так, чтобы каждый факт хранился в одном месте. Получается четыре таблицы: customers (покупатели), products (товары), orders (заказы со ссылкой на покупателя) и order_items (строки заказа со ссылками на заказ и товар). Внешние ключи закрепляют связи: база не даст добавить в заказ несуществующий товар или удалить покупателя с заказами.

Одно отступление от нормализации сознательное: цена хранится и в строке заказа, потому что цена в каталоге меняется, а сумма оплаченного заказа меняться не должна.

Дальше работают ограничения: NOT NULL для обязательных полей, CHECK (quantity > 0) против продажи минус трёх товаров, тип numeric для денег вместо чисел с плавающей точкой, которые неточно хранят копейки. Такое правило ловит ошибку при записи, а не через месяц в отчёте.

Индексы: где ускоряют и почему не срабатывают

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

В магазине из примера покупатель входит в личный кабинет по почте. Разработчик создал индекс по столбцу email, а при входе, чтобы не зависеть от регистра, пишет WHERE lower(email) = '[email protected]'. Индекс по email здесь не поможет: в нём лежат значения столбца, а запрос ищет результат функции. В разделе 11.7 документации PostgreSQL об индексах по выражениям разобран ровно этот случай: запрос с lower(col1) может использовать индекс, только если тот построен на результате этой функции.

CREATE UNIQUE INDEX customers_email_lower_idx
  ON customers (lower(email));

Из того же раздела следует вещь полезнее скорости: если объявить такой индекс уникальным, база не даст создать запись, которая отличается от существующей только регистром букв. Обычное ограничение UNIQUE на столбец считает [email protected] и [email protected] разными адресами и пропустит дубль, а уникальный индекс по выражению его остановит. Документация называет и плату: выражение вычисляется при каждой вставке и почти при каждом изменении строки, поэтому такие индексы уместны там, где чтение важнее скорости записи. Таблицу покупателей читают чаще, чем пополняют.

Резервные копии и выбор СУБД

Копия, из которой ни разу не восстанавливались, ещё не копия. Её разворачивают на отдельном сервере и проверяют, что приложение запускается, а число заказов совпадает с рабочей базой. Так всплывают подробности: документация PostgreSQL о pg_dump предупреждает, что утилита не сохраняет роли пользователей, и без их отдельной выгрузки объекты при восстановлении не получат прежних владельцев и прав. Хранят копию не на том сервере, где база, иначе отказ диска унесёт обе.

Выбор СУБД начинается с данных и нагрузки. Для заказов, платежей и учёта, где важны транзакции (выполняются все изменения или ни одного), обычно берут PostgreSQL или MySQL. Для отчётов по миллиардам строк подходит колоночный ClickHouse, для кэша — Redis, для документов с меняющейся структурой — MongoDB. SQLite хранит базу одним файлом внутри приложения и подходит для мобильных программ и прототипов.

В каком порядке осваивать

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

1. Реляционная модель: таблица, первичный и внешний ключи, связи «один ко многим» и «многие ко многим».
2. Базовый SQL: выборка, соединение, группировка, изменение данных.
3. Проектирование: нормальные формы, ограничения, выбор типов, схема в виде диаграммы.
4. Транзакции: что видит один пользователь, пока другой меняет данные.
5. Индексы и план выполнения: как понять, использует ли запрос индекс.
6. Резервное копирование, восстановление и выбор СУБД под задачу.

Начать можно бесплатно. Установите PostgreSQL и клиент DBeaver и спроектируйте базу для знакомой области — домашней библиотеки или записи в салон, — нарисовав схему до первой таблицы. Для первого знакомства с запросами подойдёт бесплатный курс Яндекс Практикума «Основы работы с базами данных и SQL»: по описанию на Учи.Онлайн, это несколько часов в тренажёре с автоматической проверкой, от устройства таблиц до группировки. Соединений, проектирования и индексов в нём нет, так что это разминка.

Упражнения и ошибки новичков

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

Типичные ошибки новичков: всё лежит в одной широкой таблице, деньги хранятся в float, даты — строками и сортируются как текст, индекс стоит на каждом столбце, копия ни разу не восстанавливалась. Проверить себя можно вопросом: что будет, если завтра сервер не включится?

Когда упражнения на одной СУБД станут привычными, полезно увидеть другие модели данных, например на онлайн-курсе Merion Academy «Базы данных с нуля»: по описанию на Учи.Онлайн, это два месяца в записи с лабораторными работами после каждого модуля. В первой части — проектирование, транзакции и ACID, особенности PostgreSQL, MS SQL Server и MySQL, во второй — MongoDB, ClickHouse, Redis и другие хранилища. Резервное копирование и подробная работа с индексами в обзоре не заявлены.

Как навык влияет на доход

Отдельной надбавки «за базы данных» обычно нет: для backend-разработчика это обязательное требование, для аналитика и специалиста 1С — умение, с которым берут более сложные задачи. Косвенно это видно по калькулятору зарплат «Хабр Карьеры»: в конце сентября 2026 года для специализации «Бэкенд-разработчик» с навыком PostgreSQL он показывал 292 616 ₽ в месяц по России для всех уровней вместе по 1 013 анкетам, для всей специализации без фильтра по навыку — 247 500 ₽ по 7 591 анкете.

Считать разницу «премией за PostgreSQL» нельзя: навыки в анкете чаще подробно указывают опытные специалисты, а разбивки по уровням в открытом доступе нет. Чтобы оценить свою ситуацию, сравните вакансии своей должности в своём регионе с требованием проектирования баз и без него и уточняйте, указана сумма до вычета налога или на руки.

Как выбрать обучение

Проверьте в программе четыре вещи: есть ли проектирование схемы, а не только запросы к готовым таблицам; разбирают ли транзакции и индексы с планом выполнения; есть ли задание на восстановление из копии; кто проверяет работы.

Тем, кто уже уверенно пишет запросы и хочет перейти к проектированию всерьёз, подойдёт онлайн-курс Нетологии «Продвинутый SQL». По описанию на Учи.Онлайн, это 14 часов теории и 28 часов практики на PostgreSQL: нормализация, проектирование, процедуры и триггеры, репликация и шардирование, связь базы с приложением, шесть домашних заданий, бизнес-игра и итоговый проект. Новичкам курс не подходит: соединения и оконные функции нужно знать заранее.

Выбирая школу, решите, что важнее: разработка, аналитика или сопровождение своей системы. От этого зависит, нужна ли широкая программа по разным хранилищам или глубокая по одной СУБД.

Сравнить школы по цене и формату можно в рейтинге онлайн-школ с обучением SQL и базам данных для разработчиков. На момент проверки в нём подробно была представлена одна программа, поэтому сверяйте условия и на сайтах школ.

Если вы можете нарисовать схему своей рабочей базы и объяснить, почему связи устроены именно так, пора переходить к индексам и копиям. Если нет — начните с маленькой базы для своей задачи: ошибки в ней обойдутся дешевле, чем в рабочей системе.