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

Зонтичный термин NoSQL на собесе лучше определить так: «NoSQL - это не отсутствие SQL, а отказ от какой-то реляционной гарантии». Redis отказался от запросов не по ключу (встроенный поиск по полям появился в нём только в Redis 8), MongoDB - от строгой схемы и (исторически) от кросс-документных транзакций, ClickHouse - от точечного UPDATE и от OLTP, Cassandra - от сильной консистентности. Взамен каждый получил своё: обычно линейное масштабирование или на порядок большую пропускную способность в своём сценарии.

Как выбирать

• Смотри на паттерн доступа, а не на объём. 500 ГБ прекрасно живут в PostgreSQL; 10 ГБ, к которым ходят 200 тыс. раз в секунду по одному ключу, - уже не живут.
• Запросы известны заранее и всегда по ключу → key-value.
• Запросы произвольные, нужны связи и отчёты → реляционная.
• Нагрузка состоит из агрегатов по сотням миллионов строк → колоночная.
• Данные образуют граф, и нужны обходы произвольной глубины → графовая.

Ответ на «можно ли всё одним классом»

Формально да: в PostgreSQL есть jsonb с GIN-индексами (документная модель), hstore и UNLOGGED-таблицы (почти key-value), расширения TimescaleDB и Citus, полнотекстовый поиск, PostGIS. Для 90 % продуктов «просто Postgres» будет правильным дефолтом. Это сильный ответ: он экономит команде операционную сложность. Но на конкретных нагрузках специализированный движок выигрывает на порядок: Redis отдаёт ключ за 50 мкс, ClickHouse считает агрегат по миллиарду строк за секунду. Поэтому зрелый продукт почти всегда держит несколько хранилищ, это и есть polyglot persistence: Postgres как источник истины, Redis как кэш, ClickHouse под аналитику, S3 под файлы.

Key-value

Redis, etcd, DynamoDB, Aerospike. Значение для БД непрозрачно, операция одна: «дай по ключу». Отсюда O(1) доступ и тривиальное шардирование: ключ хешируется, узел находится без координации. Сценарии: кэш, сессии, счётчики, rate limiter, распределённые локи, feature-флаги. А вот «найди все сессии пользователей из Москвы» так не спросишь: вторичный индекс придётся строить руками. В Redis с версии 8 для этого есть встроенный поисковый движок (Redis Query Engine, бывший модуль RediSearch), но он уже надстройка над моделью key-value.

Документные

MongoDB, Couchbase, Elasticsearch. Значение хранится как JSON-документ, и БД умеет заглядывать внутрь: индексировать поля, фильтровать по вложенным путям. Схема гибкая, документы одной коллекции могут отличаться. Годятся для каталогов товаров с разнородными атрибутами, event store, CMS, поисковых индексов. Платишь тем, что целостность между документами поддерживаешь сам, а гибкая схема на второй год превращается в «в этой коллекции восемь разных форматов, и каждый парсер знает про них по-своему».

Колоночные

ClickHouse, Vertica, BigQuery, Druid. Данные лежат по колонкам, значения одной колонки идут подряд. Соседние значения похожи, так что данные сильно сжимаются, а с диска читаются только нужные запросу колонки. SELECT sum(amount) FROM events по миллиарду строк прочитает одну колонку, а не миллиард строк целиком. Сценарии: аналитика, логи, метрики, витрины. Точечный UPDATE строки и OLTP с транзакциями сюда не ложатся.

Графовые

Neo4j, ArangoDB, JanusGraph. Рёбра хранятся как объекты первого класса с физическими указателями, поэтому переход «сосед соседа» стоит константу, а не джойн. Подходят для соцграфа, антифрода («связан ли этот аккаунт с заблокированным через 4 перехода»), рекомендаций, графов прав. В реляционной БД такой обход пишут рекурсивным CTE, и на глубине 5+ он взрывается.

Философия

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

MVCC - самое важное различие

В PostgreSQL старые версии строк лежат в самой таблице. UPDATE всегда вставляет новую версию кортежа и помечает старую. Отсюда растёт целый пласт эксплуатации, которого в MySQL нет: VACUUM, autovacuum, table bloat, HOT-обновления, transaction ID wraparound. Зато откат транзакции в PG почти бесплатен: новые версии просто никто не увидит.

В InnoDB строка обновляется на месте, а старая версия уезжает в undo-лог. Поэтому чтение «в прошлое» собирает строку по цепочке undo-записей (долгие транзакции удлиняют цепочку и замедляют чтения), а откат большой транзакции стоит дорого: изменения надо физически откатывать. Undo при этом чистит отдельный purge-поток.

Физическое хранение

PostgreSQL хранит таблицу как heap: строки лежат в файле в произвольном порядке, вторичный индекс хранит ctid (номер страницы + смещение) и ведёт прямо к версии. В InnoDB таблица сама и есть clustered index, B-tree по первичному ключу: строки лежат в листьях в порядке PK, а вторичный индекс хранит значение PK. Поэтому поиск по вторичному индексу всегда спускается по дереву дважды. На практике в MySQL PK должен быть коротким и монотонным (случайный UUID раздувает каждый вторичный индекс и рвёт страницы при вставке), а в PostgreSQL размер PK на вторичные индексы не влияет.

Строгость типов и мелочи

• PG падает с ошибкой на 'abc'::int, на переполнении int и на вставке слишком длинной строки в varchar(10). MySQL исторически усекал и выдавал warning; strict mode (дефолт с 5.7) это исправил, но «мягкое» наследие встречается до сих пор.
• Уровень изоляции по умолчанию: PG - READ COMMITTED, MySQL/InnoDB - REPEATABLE READ.
• DDL в транзакции: PG умеет откатывать CREATE TABLE, MySQL - нет (DDL делает неявный commit). Это критично для миграций: в PG упавшая миграция откатывается целиком.
• Типы: в PG массивы, jsonb с GIN, диапазоны, PostGIS, свои типы.

• DDL - CREATE, ALTER, DROP, TRUNCATE, COMMENT: структура и системный каталог.
• DML - INSERT, UPDATE, DELETE, MERGE: содержимое, построчно. SELECT иногда выделяют в DQL.
• DCL - GRANT, REVOKE: права.
• TCL - BEGIN, COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION: границы транзакции.

Механика TRUNCATE

DELETE идёт по строкам: на каждую пишет запись в WAL, помечает версию мёртвой, вызывает триггеры. Индексы при этом не трогаются, а место не освобождается: мёртвые версии и записи в индексах потом уберёт VACUUM. TRUNCATE вместо этого создаёт для таблицы новый пустой файл и меняет relfilenode в pg_class, а старый файл выбрасывает целиком. Ни одной построчной операции, ни одной записи в WAL на строку. А раз меняется запись об объекте в каталоге, операция относится к определению данных.

Практические следствия

• Работает за доли секунды независимо от размера таблицы и сразу освобождает диск.
• Берёт ACCESS EXCLUSIVE, а она блокирует даже SELECT. На проде это может встать в очередь за долгим чтением и «застопорить» таблицу целиком.
• Не вызывает BEFORE/AFTER DELETE-триггеры, только TRUNCATE-триггеры. Мягкое удаление и аудит на триггерах будут молча пропущены.
• Падает с ошибкой, если на таблицу ссылаются по FK: нужен CASCADE.
• RESTART IDENTITY сбрасывает счётчики последовательностей.

Как отвечать про выбор

• Часть строк удаляют только через DELETE, причём батчами: одна транзакция на 10 млн строк держит блокировки, раздувает WAL и оставляет гору мёртвых версий.
• Очистить таблицу целиком (тестовое окружение, перезалив справочника) - TRUNCATE, но помни про ACCESS EXCLUSIVE.
• Сущность из схемы убирает DROP, в миграции с IF EXISTS.
• «Почти всё удалить, чуть-чуть оставить» выгоднее без DELETE: «создать новую таблицу с нужным подмножеством → переименовать» дешевле и не оставляет bloat.

-- Удаляем батчами: транзакции короткие, autovacuum успевает
DELETE FROM events
WHERE ctid IN (
  SELECT ctid FROM events
  WHERE created_at < NOW() - INTERVAL '90 days'
  LIMIT 10000
);
-- в цикле, пока затронуто больше 0 строк, с паузой между итерациями

PRIMARY KEY задаёт минимальный набор колонок, который однозначно идентифицирует строку, и в таблице такой ключ один. PostgreSQL под него автоматически создаёт уникальный B-tree индекс (иначе проверять уникальность на каждой вставке пришлось бы сканом). UNIQUE отличается от PK тем, что их может быть несколько и они допускают NULL.

FOREIGN KEY требует, чтобы «значение этой колонки существовало в другой таблице». Проверка идёт в обе стороны: при INSERT/UPDATE ребёнка СУБД ищет родителя, при DELETE/UPDATE родителя смотрит, не осиротеют ли дети. Технически это системные триггеры.

Почему отсутствие индекса на FK так больно

1. JOIN. Соединение от родителя к детям идёт по неиндексированной колонке: планировщик вынужден брать Hash Join с полным сканом дочерней таблицы либо Nested Loop с Seq Scan внутри, а это уже катастрофа.
2. DELETE родителя. Чтобы проверить ON DELETE RESTRICT/CASCADE, СУБД выполняет SELECT 1 FROM child WHERE fk = $1. Без индекса это полный скан дочерней таблицы на каждую удаляемую строку. Классический инцидент: «удаление одного пользователя занимает 4 минуты».
3. То же самое при UPDATE ключевой колонки родителя.

CREATE TABLE orders (
    id          bigserial PRIMARY KEY,                     -- индекс есть
    customer_id bigint NOT NULL REFERENCES customers(id)   -- индекса нет
);
CREATE INDEX orders_customer_id_idx ON orders (customer_id);  -- заводим сами

Стоит ли вообще использовать FK

Минусы у FK есть: он замедляет запись (проверка на каждую строку), мешает шардированию (родитель и ребёнок на разных узлах) и усложняет массовые загрузки. Но это единственная гарантия целостности, которую нельзя обойти кривым скриптом, забытым условием или второй версией сервиса. Поэтому в OLTP-монолите FK держат почти всегда, а выключают точечно: в шардированных таблицах, в аналитических витринах и на время массовой загрузки (ALTER TABLE ... DROP CONSTRAINT → загрузка → добавить обратно NOT VALID и потом VALIDATE).

col = NULL честно возвращает UNKNOWN для каждой строки, включая строки, где col IS NULL: неизвестное не равно неизвестному, ведь это могут быть разные неизвестные. Сравнивать нужно через IS NULL, IS NOT NULL, IS [NOT] DISTINCT FROM.

Агрегаты

• COUNT(*) считает строки, NULL не важен.
• COUNT(col) считает только строки с col IS NOT NULL. Разница между ними сразу показывает, насколько заполнена колонка.
• SUM, AVG, MIN, MAX игнорируют NULL. AVG делит на количество НЕ-NULL, а это не то же самое, что «считать NULL нулём».
• На пустом наборе SUM возвращает NULL, а не 0, и в отчётах вылезают NULL. Лечится COALESCE(SUM(x), 0).
• GROUP BY собирает все NULL в одну группу; DISTINCT и UNION тоже считают NULL равными друг другу. Это исключения из общего правила.

Неравенство и JOIN

Самая тихая ловушка: WHERE status <> 'ban' не вернёт строки, где status IS NULL. Люди ждут «все, кроме забаненных», а получают «все, у кого статус известен и не ban». Правильно писать WHERE status IS DISTINCT FROM 'ban'. В JOIN ... ON a.x = b.x строки с NULL в ключе не соединяются ни с чем: при INNER они исчезают, при LEFT дают NULL-хвост.

NOT IN - самая опасная конструкция

-- Если подзапрос вернул хотя бы один NULL, результат всегда пустой
SELECT * FROM customers WHERE id NOT IN (SELECT customer_id FROM orders);
-- раскрывается в id <> v1 AND id <> v2 AND ... AND id <> NULL
-- последний конъюнкт = UNKNOWN, а TRUE AND UNKNOWN = UNKNOWN → строка отброшена

-- NULL-безопасно и обычно быстрее (настоящий anti-join)
SELECT * FROM customers c
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);

• INNER оставляет только совпавшие пары. Строк может стать и меньше (нет пары), и больше (несколько пар справа).
• LEFT OUTER - все строки левой таблицы; где пары нет, правая часть заполняется NULL.
• RIGHT OUTER работает зеркально. На практике его почти не пишут: читается тяжелее, проще переставить таблицы и написать LEFT.
• FULL OUTER - все строки обеих таблиц. Нужен для сверок «что есть здесь и нет там, и наоборот».
• CROSS даёт декартово произведение, без условия. Для генерации сеток (все дни × все товары) это законно, а вот случайный CROSS из-за забытого условия легко положит сервер.
• SELF JOIN - таблица с самой собой (сотрудник → менеджер).
• LATERAL - правая часть видит колонки левой: подзапрос выполняется для каждой строки слева. Отлично подходит для «top-N на группу».

-- 1) Anti-join через LEFT + IS NULL: соединяем и оставляем только «непришитые»
SELECT c.*
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

-- 2) NOT EXISTS: NULL-безопасно, планировщик строит настоящий Anti Join,
--    и он умеет останавливаться на первом совпадении
SELECT c.*
FROM customers c
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);

-- 3) EXCEPT: работает, но требует одинаковых наборов колонок и убирает дубли
SELECT id FROM customers EXCEPT SELECT customer_id FROM orders;

-- 4) NOT IN: ловушка. Один NULL в orders.customer_id, и результат пуст
SELECT * FROM customers WHERE id NOT IN (SELECT customer_id FROM orders);

Nested Loop

Для каждой строки внешней выборки ищем совпадения во внутренней. Стоимость равна N × стоимость_поиска. Хорош, когда внешняя выборка маленькая (десятки строк), а по внутренней есть индекс: получается N быстрых спусков по B-tree. Катастрофа, когда внешних строк много или внутри Seq Scan. Единственный алгоритм, который умеет неэквисоединения (<, BETWEEN, функции) и обязательный для LATERAL.

Hash Join

Фаза build: по меньшей стороне строится хеш-таблица в памяти. Фаза probe: один проход по большей стороне с проверкой по хешу. Сложность O(N + M): лучший выбор для двух крупных таблиц, но только по равенству. Главный риск: если хеш не влезает в отведённую ему память (work_mem, умноженный на hash_mem_multiplier, по умолчанию на 2), PostgreSQL разбивает данные на batches и сбрасывает их на диск. В плане это видно как Batches: 16 вместо Batches: 1 у узла Hash, и запрос проседает в разы.

Merge Join

Обе стороны читаются в отсортированном по ключу порядке и сливаются одним проходом, как merge в сортировке слиянием. Дёшев, если сортировка достаётся даром (index scan по нужному порядку); иначе к стоимости добавляются две сортировки. Часто выигрывает на очень больших наборах, где хеш не влез бы в память.

Как это использовать на практике

1. Nested Loop с loops=200000 и Seq Scan внутри почти всегда просит индекс по колонке соединения внутренней таблицы.
2. При Hash Join с Batches > 1 подними work_mem (можно локально: SET LOCAL work_mem = '256MB') или уменьши объём данных до соединения.
3. Если rows и actual rows сильно расходятся, планировщик выбрал алгоритм по неверной оценке. Помогают ANALYZE, повышение default_statistics_target или расширенная статистика CREATE STATISTICS для коррелированных колонок.

Запрос пишется в одном порядке, а выполняется в другом: SELECT стоит первым, а выполняется почти последним. Из этой цепочки механически выводятся все правила видимости имён, зубрить их не надо.

Что следует

1. Алиас из SELECT недоступен в WHERE, GROUP BY и HAVING: на момент их выполнения SELECT ещё не отработал. В ORDER BY доступен: он идёт после. (PostgreSQL допускает алиас в GROUP BY как расширение стандарта, но опираться на это не стоит.)
2. Оконные функции считаются на шаге SELECT, поэтому их нельзя писать ни в WHERE, ни в HAVING: нужен подзапрос или CTE. Так что «топ-3 в группе» всегда пишется в два уровня.
3. WHERE дешевле HAVING. Всё, что можно отфильтровать до группировки, надо фильтровать до неё: меньше строк доедет до GROUP BY, меньше памяти на хеш-агрегат.
4. LIMIT применяется последним, после сортировки, так что «взять 10 строк» не значит «прочитать 10 строк».

-- Ошибка: cnt ещё не существует, а агрегат в WHERE запрещён
SELECT customer_id, count(*) AS cnt
FROM orders
WHERE cnt > 5
GROUP BY customer_id;

-- Правильно
SELECT customer_id, count(*) AS cnt
FROM orders
WHERE created_at >= '2024-01-01'   -- фильтр строк: дёшево, до группировки
GROUP BY customer_id
HAVING count(*) > 5                -- фильтр групп: только по агрегату
ORDER BY cnt DESC                  -- здесь алиас уже виден
LIMIT 10;

Скалярный подзапрос возвращает ровно одно значение и может стоять вместо выражения: SELECT (SELECT max(id) FROM orders). Если он вдруг вернёт больше одной строки, получишь ошибку времени выполнения, а не пустой результат; на этом ловят. Коррелированный использует колонки внешнего запроса, а значит, его нельзя вычислить один раз заранее.

-- Коррелированный: для каждой строки employees считаем среднее по её отделу
SELECT e.name, e.salary,
       (SELECT avg(e2.salary) FROM employees e2 WHERE e2.dept_id = e.dept_id) AS dept_avg
FROM employees e;
-- на 1 млн сотрудников подзапрос выполнится до 1 млн раз

-- Оконная функция: один проход, одна сортировка/хеш
SELECT e.name, e.salary,
       avg(e.salary) OVER (PARTITION BY e.dept_id) AS dept_avg
FROM employees e;

-- Или JOIN с предагрегатом: каждый отдел посчитан ровно один раз
SELECT e.name, e.salary, d.dept_avg
FROM employees e
JOIN (SELECT dept_id, avg(salary) AS dept_avg FROM employees GROUP BY dept_id) d
  ON d.dept_id = e.dept_id;

Когда планировщик спасает, а когда нет

PostgreSQL умеет декоррелировать часть подзапросов: EXISTS и IN обычно превращаются в Semi Join, NOT EXISTS - в Anti Join, и это работает быстро. Но декорреляция не срабатывает, если внутри есть LIMIT, ORDER BY с ограничением, агрегат по внешней колонке, volatile-функция или подзапрос стоит в списке SELECT. В плане это видно как SubPlan с большим loops, и это верный признак, что запрос пора переписать.

Что чем заменять

-- LATERAL: последний заказ каждого клиента, с попаданием в индекс
SELECT c.id, c.name, o.id AS last_order, o.created_at
FROM customers c
LEFT JOIN LATERAL (
    SELECT o.id, o.created_at
    FROM orders o
    WHERE o.customer_id = c.id
    ORDER BY o.created_at DESC
    LIMIT 1
) o ON TRUE;
-- нужен индекс (customer_id, created_at DESC)

Зачем

• Читаемость: длинный запрос разбивается на именованные шаги вместо вложенности в пять уровней.
• Результат можно переиспользовать внутри одного запроса.
• Рекурсия: без неё иерархии и графы в SQL не обойти.
• DML-конвейеры: WITH ... AS (DELETE ... RETURNING *) INSERT ... переносит данные одним атомарным запросом.

Что изменилось в PG 12

До PostgreSQL 12 любой WITH был барьером оптимизации: он выполнялся целиком во временный набор, и предикаты внешнего запроса внутрь не проталкивались. Если снаружи стоял WHERE id = 5, а CTE выбирал миллион строк, сначала считался миллион, а потом отбрасывалось всё, кроме одной. С PG 12 CTE, который используется ровно один раз, не рекурсивен и не содержит DML и volatile-функций, по умолчанию инлайнится и ведёт себя как обычный подзапрос. Явно поведение задают через AS MATERIALIZED и AS NOT MATERIALIZED.

-- MATERIALIZED явно - для барьера оптимизации; CTE с двумя и больше ссылками PG 12+ материализует и сам
WITH heavy AS MATERIALIZED (
    SELECT ... FROM big_table WHERE ...
)
SELECT * FROM heavy a JOIN heavy b ON ... ;

-- Рекурсивный CTE: якорь UNION ALL шаг рекурсии
WITH RECURSIVE subs AS (
    SELECT id, name, manager_id, 1 AS depth, ARRAY[id] AS path
    FROM employees WHERE id = 1                  -- якорь
  UNION ALL
    SELECT e.id, e.name, e.manager_id, s.depth + 1, s.path || e.id
    FROM employees e
    JOIN subs s ON e.manager_id = s.id           -- шаг
    WHERE NOT e.id = ANY(s.path)                 -- защита от цикла в данных
      AND s.depth < 50                           -- страховка от бесконечности
)
SELECT * FROM subs ORDER BY depth, id;

От агрегата окно отличается так: GROUP BY превращает 1000 строк в 10, а окно оставляет все 1000 и каждой приписывает значение, посчитанное по её группе. PARTITION BY режет строки на окна, ORDER BY внутри OVER задаёт порядок внутри окна, ROWS/RANGE задают рамку (если есть ORDER BY, по умолчанию она идёт от начала окна до текущей строки, точнее до последней строки с тем же значением ORDER BY, отсюда «нарастающий итог»).

-- Топ-3 товара по выручке внутри каждой категории
SELECT category_id, product_id, revenue
FROM (
    SELECT category_id, product_id, sum(amount) AS revenue,
           ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY sum(amount) DESC) AS rn
    FROM sales
    GROUP BY category_id, product_id          -- окно считается после агрегации
) t
WHERE rn <= 3
ORDER BY category_id, revenue DESC;

-- Интервал между заказами клиента
SELECT customer_id, created_at,
       created_at - LAG(created_at) OVER (PARTITION BY customer_id ORDER BY created_at) AS gap
FROM orders;

-- Именованное окно, если оно повторяется
SELECT customer_id, amount,
       sum(amount) OVER w AS running_total,
       ROW_NUMBER()  OVER w AS n
FROM orders
WINDOW w AS (PARTITION BY customer_id ORDER BY created_at);

VIEW

При обращении планировщик подставляет тело представления в запрос и оптимизирует всё вместе (view expansion). Значит, данные всегда свежие, места не занимают, но каждая выборка стоит столько, сколько стоит исходный запрос. Вьюха инкапсулирует логику, служит слоем совместимости при переименовании колонок и разграничивает права («этой роли - только вьюху без персональных данных»). Но вьюхи поверх вьюх дают планы, которые невозможно читать, а тяжёлая вьюха тяжела на каждом обращении. Простая вьюха обновляема напрямую; сложная - только через INSTEAD OF-триггеры или CREATE RULE.

MATERIALIZED VIEW

Хранит результат физически, поддерживает свои индексы, читается как обычная таблица. Обновляется только явно:

• REFRESH MATERIALIZED VIEW mv берёт ACCESS EXCLUSIVE: на всё время обновления вьюха недоступна даже для чтения.
• REFRESH MATERIALIZED VIEW CONCURRENTLY mv не блокирует читателей, но требует уникального индекса на вьюхе и работает заметно дольше (обновление идёт через сравнение со старой версией).
• С WITH NO DATA вьюха создаётся пустой и до первого REFRESH не читается.

В PostgreSQL нет инкрементального обновления «из коробки»: REFRESH пересчитывает всё. Если данных много, обычно заводят расписание (pg_cron / джоб в приложении) или собственную «сводную таблицу», которую обновляют триггерами или батчами.

Формы своими словами

• 1НФ: в ячейке лежит одно атомарное значение, повторяющихся групп нет. Нарушение: phones = '+7999..., +7495...' одной строкой или колонки phone1, phone2, phone3. Лечится отдельной таблицей.
• 2НФ: 1НФ + каждый неключевой атрибут зависит от всего составного ключа, а не от его части. Нарушение: ключ (order_id, product_id), а в строке лежит order_date, который зависит только от order_id. Актуальна только при составном ключе.
• 3НФ: 2НФ + нет транзитивных зависимостей: неключевые атрибуты не зависят друг от друга. Нарушение: в orders лежат city_id и city_name, а имя зависит от id, не от заказа. Переименовали город, и надо обновлять миллион строк: часть обновится, а часть нет.

Мнемоника: «каждый неключевой атрибут зависит от ключа, от всего ключа и ни от чего, кроме ключа». Дальше идут НФБК, 4НФ, 5НФ; на собесе достаточно упомянуть, что они существуют и лечат более экзотические аномалии.

Что именно чинит нормализация

Не «красоту», а три аномалии: обновления (одно и то же имя города в миллионе строк обновится не везде), вставки (нельзя завести город, пока нет заказа в нём) и удаления (удалили последний заказ - потеряли факт существования города).

Когда денормализовать

1. Джойн доказанно стал узким местом: есть план и цифры, а не ощущение.
2. Дублируемые данные меняются редко или не меняются вовсе.
3. Есть механизм поддержания согласованности: триггер, материализованная вьюха, пересчёт по расписанию, событие в брокере.

• NOT NULL - самый дешёвый и самый недооценённый. Убирает целый класс багов с трёхзначной логикой. Ставь по умолчанию, ослабляй осознанно.
• UNIQUE реализуется уникальным индексом. Помни: несколько NULL допускаются (они «разные»); с PG 15 есть UNIQUE NULLS NOT DISTINCT.
• CHECK проверяет предикат на каждой строке. Именуй явно: имя приходит в текст ошибки, и по нему удобно ветвиться в коде и искать в логах. Не может ссылаться на другие таблицы и должен вести себя как IMMUTABLE: CHECK (created_at <= now()) PostgreSQL примет, но проверит только при записи, и восстановление из дампа может на нём упасть.
• EXCLUDE, ещё один недооценённый констрейнт PostgreSQL, требует: «никакие две строки не должны конфликтовать по оператору». Каноничный кейс: запрет пересечения интервалов броней, EXCLUDE USING gist (room_id WITH =, period WITH &&). Оператор = по обычной колонке вроде int GiST понимает только с расширением btree_gist.

-- Частичный уникальный индекс: email уникален только среди неудалённых
CREATE UNIQUE INDEX users_email_uniq ON users (LOWER(email)) WHERE deleted_at IS NULL;

-- Именованный CHECK: имя попадёт в текст ошибки
ALTER TABLE accounts ADD CONSTRAINT accounts_balance_nonneg CHECK (balance >= 0);

-- NOT VALID: добавить мгновенно, старые строки проверить потом без тяжёлой блокировки
ALTER TABLE orders ADD CONSTRAINT orders_total_pos CHECK (total > 0) NOT VALID;
ALTER TABLE orders VALIDATE CONSTRAINT orders_total_pos;

-- Отложенная проверка: до COMMIT можно временно нарушить (циклические ссылки)
ALTER TABLE a ADD CONSTRAINT a_b_fk FOREIGN KEY (b_id) REFERENCES b(id)
  DEFERRABLE INITIALLY DEFERRED;