Реляционные базы данных

Данные организованы в связанные таблицы

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

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    total DECIMAL(12, 2) NOT NULL
);

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

Ограничения поддерживают целостность

Primary key обеспечивает уникальность записи, foreign key может контролировать связь между таблицами, а NOT NULL и другие ограничения фиксируют допустимую форму данных.

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

Транзакции объединяют связанные изменения

Если бизнес-операция требует нескольких изменений, транзакция позволяет рассматривать их как единое целое. Например, создание заказа и его позиций не должно оставлять половину результата при ошибке посередине.

BEGIN
  insert order
  insert items
COMMIT

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

Индексы ускоряют нужные запросы

Без подходящего индекса базе часто приходится просматривать гораздо больше строк, чем нужно. Индекс создаёт дополнительную структуру для быстрого поиска по выбранным полям.

Это не бесплатное ускорение: индекс занимает место и должен обновляться при записи. Поэтому индексируют реальные паттерны запросов, а не все возможные комбинации колонок.

Где появляется сложность

При очень больших объёмах и распределении по нескольким узлам становятся важны репликация, партиционирование и стоимость запросов между разделёнными данными. Это не делает реляционную модель плохой, но заставляет проектировать доступ к данным осознанно.