Проектирование базы данных: таблицы, связи и индексы

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

Реляционная модель простыми словами

Данные хранятся в таблицах: строки — записи, столбцы — атрибуты. Клиенты в одной таблице, заказы в другой, товары в третьей. Таблицы связаны ключами: в каждом заказе хранится идентификатор клиента, а не его имя и телефон. Язык SQL позволяет собирать данные из связанных таблиц одним запросом. Распространённые СУБД — PostgreSQL, MySQL, Microsoft SQL Server.

Шаги проектирования

1. Выделить сущности предметной области: клиент, заказ, позиция заказа, товар, склад, сотрудник, оплата.
2. Определить атрибуты каждой сущности и их типы: текст, число, дата, деньги, флаг.
3. Определить связи: один клиент — много заказов; один заказ — много позиций; товар может лежать на многих складах.
4. Нормализовать: убрать дублирование данных.
5. Добавить ограничения и индексы.
6. Проверить модель на реальных сценариях и отчётах.

Ключи и связи

Первичный ключ — уникальный идентификатор записи. Внешний ключ — ссылка на запись другой таблицы. Связь «многие ко многим», например товары и категории, реализуется через промежуточную таблицу. Внешние ключи с ограничениями не позволят, например, создать заказ несуществующего клиента или удалить товар, по которому есть продажи.

Нормализация

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

Индексы

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

Ограничения целостности

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

История и аудит

Бизнесу часто нужно знать, кто и когда изменил запись: цену, статус заказа, лимит клиента. Это закладывается сразу: поля «создано/изменено кем и когда», отдельные таблицы истории для важных сущностей. Удаление нередко заменяют пометкой «удалено», чтобы не терять связанные данные.

Типичные ошибки

• Всё в одной большой таблице со столбцами «товар1», «товар2», «товар3»
• Статусы и типы хранятся свободным текстом с разным написанием
• Нет внешних ключей, и через год в базе полно «висящих» записей
• Телефоны в разных форматах, из-за чего поиск клиента не находит дубликаты
• Отчёты строятся по рабочей базе тяжёлыми запросами в часы пик
• Нет резервного копирования и проверки восстановления

Что спросить у разработчика

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