Дизайн схемы: нормализуй, потом денормализуй осознанно

Сначала нормализуй: один факт, одно место

Нормализация — это дефолт, и правило большого пальца, схватывающее бóльшую часть: каждый факт живёт ровно в одном месте. Email клиента хранится один раз, на строке users; заказ ссылается на пользователя по id и никогда не копирует email. Когда email меняется, ты обновляешь одну строку, и каждый заказ автоматически отражает истину, потому что её никогда не дублировали. (Глава relational-model трека databases разбирает нормальные формы формально; здесь мы фокусируемся на инженерном суждении.)

Выигрыш — целостность обновления: нет способа, чтобы две копии факта разошлись, потому что копия одна. Цена — что чтение полной картины требует джойнов — чтобы показать заказ с текущим именем клиента, ты джойнишь orders к users. Для подавляющего большинства OLTP-нагрузок (Online Transaction Processing — оперативная обработка транзакций) этот джойн дёшев (индексированный поиск), а целостность бесценна. Начинай нормализованно. Всегда.

Моделируй типами Postgres, не строками

Сквозная нить всего раздела: схема, опирающаяся на систему типов Postgres, обеспечивается движком; stringly-typed схема толкает эту работу в хрупкий код приложения. Конкретно, предпочитай:

• enum status order_status (или CHECK ... IN) вместо свободного status text, который может держать 'Paid', 'paid' и 'PAID';
• tstzrange с ограничением EXCLUDE вместо двух text-колонок с ISO-строками, которые приложение должно парсить и сравнивать;
• numeric/целые центы вместо text «amount»; timestamptz вместо text-даты; tags text[] (или джойн-таблицу) вместо строки через запятую;
• jsonb-документ вместо сериализованного блоба, который база не может индексировать или валидировать;
• domain (CREATE DOMAIN email AS text CHECK (value ~ '^[^@]+@[^@]+$')), чтобы прикрепить переиспользуемое ограничение к семантическому типу.

Каждое из этого переносит правило из «приложение помнит проверить» в «движок гарантирует». Stringly-typed колонка — отложенный баг: сегодня она принимает мусор, а позже всплывает он продовым инцидентом.

Суррогатные против натуральных ключей

Натуральный ключ — колонка, которая уже реальный идентификатор (ISO-код страны, SKU, email). Суррогатный ключ — бессмысленный id, сгенерированный движком (bigint identity или uuid). Суждение:

• Суррогат — безопасный дефолт для первичного ключа. Он стабилен (клиент может сменить email; его id никогда не меняется), компактен и единообразен. Внешние ключи указывают на суррогат, так что смена натурального значения не каскадит через всю базу.
• Натуральные ключи заслуживают место как UNIQUE-ограничения (тебе всё равно нужен users.email UNIQUE) и изредка как первичный ключ, когда значение действительно неизменно и внешне осмысленно — таблица currencies(code) с ключом 'USD', 'EUR'. Даже тогда осторожно: «неизменные» идентификаторы имеют привычку меняться (компании переименовываются, страны разделяются).

Прагматичное правило: суррогатный первичный ключ + натуральные уникальные ограничения. Получаешь стабильную цель джойна и всё равно обеспечиваешь реальное правило уникальности.

Денормализуй осознанно — и держи согласованным

Денормализация — это оптимизация производительности, к которой тянешься после замеров, а не стартовая поза. Она верна, когда чтение горячее, джойн действительно дорог на твоём масштабе, а дублируемый факт редко меняется — предвычисленный order_total, кешированный comment_count, дружественная поиску копия. Не подлежащее переговорам: денормализованная копия должна держаться согласованной движком, а не надеждой. Два чистых способа:

-- 1) STORED generated колонка: вывод внутри той же строки, всегда верна, без триггера
ALTER TABLE order_items
  ADD COLUMN line_total bigint GENERATED ALWAYS AS (qty * unit_price_cents) STORED;

-- 2) триггер: поддержка межстрочного агрегата (например orders.item_count) при смене позиции
CREATE FUNCTION bump_item_count() RETURNS trigger AS $$
BEGIN
  UPDATE orders SET item_count = item_count + 1 WHERE id = NEW.order_id;
  RETURN NEW;
END $$ LANGUAGE plpgsql;

STORED generated колонка обрабатывает выводы той же строки бесплатно (без триггера, не может дрейфовать). Межстрочные агрегаты требуют триггера или периодически обновляемого materialized view — и это реальная цена сопровождения, которую берёшь осознанно. Кардинальный грех — ошибка из Hook: скопировать факт и затем довериться приложению обновить каждую копию. Денормализация, поддерживаемая приложением, дрейфует; поддерживаемая движком — нет.