Краткий ответ

Автоматическая генерация значения решает только задачу получения новых значений при вставке. Она не гарантирует уникальность уже существующих или явно заданных значений и не сообщает СУБД, что столбец идентифицирует строку. Для этого отдельно требуется ограничение PRIMARY KEY или, при другой модели целостности, UNIQUE вместе с подходящим ограничением обязательности.

Исторический контекст

Автоматическая генерация идентификаторов появилась как декларативная замена ручному управлению счетчиками, последовательностями и вычислением следующего значения в прикладном коде. Такой подход уменьшает гонки между параллельными транзакциями и переносит выдачу новых номеров в СУБД.

Однако генератор значений и ограничение целостности решают разные задачи. Первый отвечает на вопрос «как получить значение по умолчанию», второе — «какие значения допустимы и может ли столбец однозначно идентифицировать строку».

Постановка проблемы

Если объявить только автоматическую генерацию, приложение может явно передать значение, если режим столбца это допускает, либо импортировать конфликтующие данные отдельным способом. Даже если в обычном сценарии все значения выдаёт генератор, это не является декларацией уникальности для СУБД.

Без первичного или уникального ограничения база не обязана отклонять дубликаты. В результате внешний ключ нельзя надёжно направить на такой столбец, а поиск строки по предполагаемому идентификатору может возвращать несколько строк.

Подробное решение

Identity-столбец задаёт правило генерации значения, когда значение не указано при вставке. PRIMARY KEY задаёт ключ сущности: значения должны быть уникальными, не пустыми и пригодными для ссылок из других таблиц.

Минимальная конструкция обычно выглядит так:

CREATE TABLE orders (
    order_id INTEGER GENERATED ALWAYS AS IDENTITY,
    description VARCHAR(100),
    CONSTRAINT orders_pk PRIMARY KEY (order_id)
);

Здесь генератор выдаёт новые значения, а первичный ключ запрещает дубликаты и значения NULL. Точный синтаксис identity-столбцов, поддерживаемые параметры и поведение при явной передаче значения зависят от СУБД, поэтому миграции нужно проверять по документации конкретной системы.

Identity не обязан быть единственным способом формирования ключа: значение может получать отдельная последовательность, UUID или приложение. И наоборот, уникальный ключ может быть составным и не иметь автоматической генерации вообще.

Генераторы также обычно не обещают непрерывную нумерацию. Откат транзакции, удаление строки или пропуск зарезервированного значения могут оставить разрывы; для ключа это нормально, поскольку его задача — идентификация, а не нумерация документов без пропусков.

Ситуация из практики

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

Рассматривались два варианта. Проверять уникальность в приложении было бы недостаточно: параллельные транзакции всё равно могли бы одновременно пройти такую проверку. Добавление отдельного UNIQUE решало дубликаты, но для обязательного главного идентификатора более ясно и полно выражало намерение через PRIMARY KEY.

Выбрали identity вместе с первичным ключом. Генерация осталась ответственностью СУБД, а ограничение стало последней линией защиты при импорте, ручных вставках и ошибках приложения; внешние ключи получили надёжную цель для ссылок.

Что кандидаты часто упускают

1. Чем отличаются режимы GENERATED ALWAYS и GENERATED BY DEFAULT?

GENERATED ALWAYS требует, чтобы обычная вставка использовала значение, созданное системой; явное значение обычно допускается только через специальный явно указанный режим, если его предоставляет СУБД. GENERATED BY DEFAULT использует генератор, когда значение не передано, но обычно позволяет приложению указать собственное значение.

Это важно при миграциях и восстановлении данных: режим BY DEFAULT удобнее для импорта заранее известных идентификаторов, но требует контроля конфликтов с уже выданными значениями генератора.

2. Гарантирует ли identity последовательные номера без пропусков?

Нет. Генератор может выдать значение, после чего транзакция откатится; кроме того, СУБД может заранее резервировать диапазоны значений для производительности. Удаление строки также не приводит к повторному использованию её номера.

Если нужны номера без пропусков, это уже отдельная бизнес-задача с существенной ценой: потребуется сериализация выдачи номеров или специальный механизм, который снижает параллелизм и усложняет восстановление после сбоев.

3. Достаточно ли UNIQUE вместо PRIMARY KEY для идентификатора?

UNIQUE обеспечивает уникальность, но семантически не объявляет столбец главным идентификатором таблицы. В зависимости от СУБД и конкретного определения уникального ограничения оно может иначе обрабатывать NULL, тогда как первичный ключ предназначен для обязательной идентификации строки.

Если у сущности один главный ключ и он должен быть обязательным, обычно выбирают PRIMARY KEY. UNIQUE уместен для альтернативного ключа, например уникального внешнего номера, который не является основным идентификатором строки.