Зачем валидировать на уровне БД

«Это же проверит код на бэкенде, зачем дублировать в базе?» — типичный вопрос. Ответ: код бэкенда — не последняя линия обороны. Базу читают и пишут:

• Несколько микросервисов, написанных разными командами.
• Скрипты миграции данных, которые обходят application layer.
• Аналитики через psql и DBeaver.
• Бывают и баги — забыли валидацию, пропустили проверку в новом эндпоинте.

CHECK-ограничения — это декларативная валидация, гарантированная самой СУБД. Никакой код её не обойдёт, кроме явного ALTER TABLE ... DROP CONSTRAINT. Это и есть «последняя линия обороны».

CHECK — синтаксис и места применения

CHECK (предикат) можно навесить:

• На колонку — обычно при CREATE TABLE или ALTER TABLE ADD COLUMN.
• На таблицу — отдельным CONSTRAINT после колонок, может ссылаться на несколько столбцов.

CREATE TABLE products (
  id          SERIAL PRIMARY KEY,
  sku         TEXT NOT NULL UNIQUE,
  name        TEXT NOT NULL CHECK (length(name) > 0),
  price_cents INT  NOT NULL CHECK (price_cents > 0),
  in_stock    INT  NOT NULL DEFAULT 0 CHECK (in_stock >= 0),
  CONSTRAINT sku_format CHECK (sku ~ '^[A-Z]{2}-[0-9]{3}$')
);

Первые три CHECK — на колонках. Последний — табличный, и в нём

Условие может использовать

Третий INSERT получит ошибку: new row for relation "inventory" violates check constraint "inventory_qty_check". Транзакция откатится.

CHECK и NULL — снова трёхзначная логика

CHECK пропускает строку, если предикат не FALSE. То есть TRUE и NULL оба считаются «прошедшими». Это сделано специально: иначе колонки с пропусками было бы невозможно проектировать.

CHECK (price_cents > 0)

Эта проверка не отвергнет строку с price_cents = NULL. Чтобы запретить и NULL, и неположительные значения, нужно:

price_cents INT NOT NULL CHECK (price_cents > 0)

NOT NULL отвечает за NULL, CHECK — за остальное. Это разные сущности.

UPDATE и CHECK: что происходит при «провале»

Если UPDATE нарушает CHECK на одной из строк, вся UPDATE-операция откатывается. Не только эта строка — а вся транзакция, в которой шёл UPDATE.

UPDATE inventory SET qty = qty - 100;  -- если у какой-то строки qty станет < 0, весь UPDATE откатывается

Это сильное гарантирование атомарности. Если хочется «обновить только те строки, для которых это безопасно» — нужно явно фильтровать в WHERE:

UPDATE inventory SET qty = qty - 100 WHERE qty >= 100;

После ошибки таблица не изменилась — это и есть атомарность.

ENUM vs CHECK + TEXT — что выбрать

В PostgreSQL есть отдельный тип ENUM (создаётся через CREATE TYPE ... AS ENUM (...)). Альтернатива — TEXT колонка с CHECK (col IN ('a', 'b', 'c')).

Кратко:

В нашей схеме orders.status сделан через CHECK — именно по причине гибкости:

status TEXT NOT NULL CHECK (status IN ('pending','paid','shipped','delivered','cancelled','refunded'))

Второй запрос получит ошибку violates check constraint "orders_status_check".

DOMAIN — типы с встроенной валидацией

DOMAIN — это пользовательский тип, привязанный к существующему, но с дополнительными ограничениями (CHECK, NOT NULL, DEFAULT). Полезен, когда одно и то же ограничение нужно применить во многих таблицах.

CREATE DOMAIN email_addr AS TEXT
  CHECK (VALUE ~* '^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$');

CREATE TABLE users (
  id    SERIAL PRIMARY KEY,
  email email_addr NOT NULL UNIQUE
);

Теперь email-валидация регуляркой не дублируется в каждой таблице с email-колонкой — она зашита в сам тип. Поменять регулярку — ALTER DOMAIN, и она вступит в силу везде.

DOMAIN используется реже, чем заслуживает, — но в проектах с десятком таблиц на похожих типах он сильно экономит время.

NOT VALID — добавить CHECK без проверки старых данных

В больших таблицах добавление CHECK может занять часы — придётся прогнать предикат по всем строкам. PostgreSQL даёт способ обойти это:

ALTER TABLE huge_table ADD CONSTRAINT no_negatives CHECK (amount >= 0) NOT VALID;

NOT VALID говорит: новые строки и UPDATE-ы проверяй, но старые данные не трогай. Потом, в окно низкой нагрузки, можно сделать ALTER TABLE ... VALIDATE CONSTRAINT ... — это запустит проверку существующих строк.

Это критичная опция для миграций на горячих таблицах. Без NOT VALID миграция может заблокировать таблицу на десятки минут.

Чек-лист

• CHECK (предикат) — декларативная валидация на уровне БД, обходится только DROP CONSTRAINT.
• Условие проверяется при INSERT и UPDATE на новой версии строки. При DELETE — нет.
• CHECK пропускает строки, где предикат TRUE или NULL. Чтобы запретить NULL — нужен NOT NULL.
• Если UPDATE нарушает CHECK хоть на одной строке — вся операция откатывается.
• ENUM хорош для стабильных перечислений; TEXT + CHECK IN (...) — для эволюционирующих.
• DOMAIN — переиспользуемый тип с встроенным CHECK. Полезен в проектах с повторяющимися правилами.
• ALTER TABLE ADD CONSTRAINT ... NOT VALID — добавить CHECK без блокировки старых данных. Потом VALIDATE в окно низкой нагрузки.