Ограничения, ключи и типы данных Postgres

Команда хранит деньги в REAL. После года накопленных транзакций обнаруживаются расхождения на уровне центов, которые невозможно объяснить. Тип и был ошибкой — арифметика float теряет точность. Исправление — изменение схемы, затрагивающее каждую строку.

Реляционная модель Кодда vs SQL

Статья Эдгара Кодда 1970 года формализовала отношения как наборы кортежей из типизированных доменов и определила замкнутую алгебру операций (выборка, проекция, соединение, объединение, пересечение, разность) — замкнутую потому, что каждая операция принимает отношения на вход и возвращает отношение на выход. SQL — нестрогая реализация этой алгебры; он добавляет NULL (что Кодду не нравилось), ORDER (строки концептуально неупорядочены) и дублирующиеся строки (в отношениях дублей нет). Знание этого разрыва объясняет шероховатости:

• NULL = NULL — это NULL, не true: трёхзначная логика.
• ORDER BY обязателен для гарантии порядка строк — без него движок вернёт любой порядок.
• DISTINCT существует потому, что движок должен хранить дубли, пока вы не попросите иначе.

Воспринимайте разрыв как «SQL = реляционная алгебра плюс практические компромиссы» — и неожиданности перестанут удивлять.

Пять видов ограничений

Суррогатные vs натуральные ключи

Натуральный ключ — данные, уже существующие в бизнес-домене (email пользователя, SKU продукта, номер заказа). Суррогатный ключ — генерируемый базой, непрозрачный, значимый только внутри базы (BIGSERIAL, UUID).

Продакшн-дефолт в 2026: суррогатный ключ как primary key плюс ограничение UNIQUE NOT NULL на бизнес-натуральный ключ. Почему: натуральные ключи меняются (клиент меняет email), а изменение primary key каскадирует через каждый ссылающийся foreign key — операционно дорогостояще и часто невозможно при масштабе. Суррогатные ключи никогда не меняются.

Исключение: чистые join-таблицы (favourites: user_id, item_id) часто используют композит из foreign keys как PK — сама связь и есть идентичность, суррогат не нужен.

UUID vs BIGSERIAL. UUID глобально уникальны (хороши для распределённых вставок, мультирегионов, offline-first клиентов), но больше (16 байт против 8) и хуже для локальности индекса (случайные UUIDv4 фрагментируют B-tree). UUIDv7 (упорядоченный по времени, RFC 9562) решает проблему локальности и является современным дефолтом там, где нужен UUID. BIGSERIAL меньше, последователен и cache-friendly — выбирайте его, когда глобально уникальные ID не нужны.

Типы данных Postgres: выбирайте минимально необходимый

У Postgres богатейшая система типов среди всех популярных баз данных. Тип — первый рубеж ограничения: правильно типизированная колонка отсекает 80% плохих данных до того, как сработает любое CHECK ограничение.