Массивы и enum: когда каждый бьёт строку

Нативные массивы: настоящий первоклассный тип

Массивы Postgres — не хак: любой тип может быть массивом (int[], text[], даже jsonb[]), с синтаксисом литерала и богатым набором операторов. Они блестят для маленького, упорядоченного, однотабличного списка, к которому ты никогда не джойнишь: теги строки, набор флагов, путь.

CREATE TABLE products (
  id   bigint PRIMARY KEY,
  tags text[] NOT NULL DEFAULT '{}'        -- литерал массива: пустой массив
);

INSERT INTO products (id, tags) VALUES (1, '{sale,featured,new}');

SELECT * FROM products WHERE 'sale' = ANY(tags);      -- проверка вхождения
SELECT * FROM products WHERE tags @> '{sale,new}';    -- содержит ВСЕ из этих
SELECT id, unnest(tags) AS tag FROM products;         -- развернуть в строки
SELECT array_agg(id) FROM products WHERE 'sale' = ANY(tags);  -- свернуть в массив

Ключевые операторы: ANY(arr) / ALL(arr) для «совпадает с каким-то / каждым элементом», @> containment («содержит все из»), unnest() развернуть массив в строки и array_agg() свернуть строки обратно в массив. И массивы индексируемы — GIN (Generalized Inverted Index, обобщённый инвертированный индекс) на text[] делает запросы containment @> и = ANY быстрыми, ровно как у JSONB.

CREATE INDEX ON products USING gin (tags);   -- теперь @> и = ANY используют индекс

Когда ловишь себя на том, что хочешь сохранить список связанных id в массиве, — сделай паузу здесь. Загвоздка, решающая всё: нельзя поставить внешний ключ на элемент массива. Поле tag_id int[] может держать id, которых нет ни в одной таблице tags, и Postgres не остановит это. Массивы меняют ссылочную целостность и производительность джойнов на локальность и простоту. Отлично для самодостаточного списка; неверно для связи.

Enum: упорядоченный и компактный

enum — кастомный тип с фиксированным, упорядоченным набором меток-значений. Он компактен (хранится как 4-байтовый oid, а не полный текст), и порядок осмыслен — сравнения следуют порядку объявления, что идеально для вещей вроде степени серьёзности или стадий workflow.

CREATE TYPE order_status AS ENUM ('pending', 'paid', 'shipped', 'delivered');

CREATE TABLE orders (
  id     bigint PRIMARY KEY,
  status order_status NOT NULL DEFAULT 'pending'
);

-- упорядочивание следует порядку объявления, не алфавиту:
SELECT * FROM orders WHERE status >= 'shipped';   -- shipped + delivered

Это упорядочивание — суперсила enum над CHECK (status IN (...)) на текстовой колонке: произвольные строки нельзя естественно упорядочить по стадии workflow, а сравнения enum просто работают.

Боль ALTER у enum

Вот компромисс, кусающий в проде. ADD VALUE в enum прост и онлайн в современном Postgres:

ALTER TYPE order_status ADD VALUE 'returned';            -- в конец, нормально
ALTER TYPE order_status ADD VALUE 'cancelled' BEFORE 'paid';  -- с позицией, тоже нормально

Но нельзя удалить или переименовать-прочь значение без фактической пересборки типа: создать новый enum, изменить каждую колонку, использующую его, удалить старый тип и пересоздать зависимые представления и функции — настоящая миграция, не однострочник. Enum — храповик в одну сторону: легко добавлять, больно сжимать. Если твой набор значений действительно фиксирован на жизнь системы (уровни серьёзности, группы крови), компактность и порядок enum — чистый выигрыш. Если он churn’ит — категории, которые бизнес постоянно переустраивает, — жёсткость становится повторяющимся налогом.

Enum против CHECK против lookup-таблицы

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

• Enum — набор значений фиксирован и порядок важен. Компактно, быстро, самодокументируемо; боль ALTER при удалении.
• CHECK (status IN ('a','b')) на колонке text — маленький набор, порядок не нужен, легко править (просто измени ограничение). Без порядка, чуть больше хранения, без метаданных.
• Lookup-таблица (statuses(code text PK, label text, sort_order int, is_active bool)) с внешним ключом — реляционный ответ, когда набор развивается, нужны метаданные или нужен внешний ключ. Платишь джойном, но можешь добавлять/удалять/переименовывать значения обычными INSERT/UPDATE/DELETE и прикрепить сколько угодно атрибутов.

Сеньорская эвристика: фиксировано + упорядочено → enum; маленькое + гибкое → CHECK; развивается или нужны метаданные → lookup-таблица. Дефолт на lookup-таблицу редко неверен; дефолт на enum для churn’ящего набора — это будущая миграция, которую ты сам себе запланировал.