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

Столбец-идентификатор связывает генерацию значения с конкретным столбцом, тогда как последовательность является самостоятельным объектом схемы. Поэтому идентификатор удобнее, когда генератор нужен только одной таблице, а последовательность — когда один источник нумерации должен независимо использоваться несколькими объектами или управляться отдельно.

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

Автоматическая генерация ключей появилась как средство отделить выдачу уникальных значений от прикладного кода. Это устраняет гонки между параллельными вставками и не требует сначала вычислять максимальный существующий ключ.

Последовательность решает эту задачу как отдельный объект схемы. Identity-столбец предоставляет тот же общий механизм через свойства столбца и скрывает детали отдельного генератора от пользователя.

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

Выбор влияет не только на синтаксис вставки. Он определяет жизненный цикл генератора, возможность совместного использования, права доступа, поведение миграций и последствия удаления или переноса таблицы.

Если генератор нужен нескольким таблицам, identity может оказаться слишком тесно связанным с одной таблицей. Если же создать отдельную последовательность без необходимости, схема усложнится: появится объект, которому нужно отдельно выдавать права, включать его в миграции и контролировать его удаление.

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

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

Последовательность — самостоятельный объект с текущим значением и правилами увеличения. Несколько таблиц могут получать значения из одной последовательности, но тогда уникальность между ними обеспечивается общим генератором, а не отдельными ограничениями таблиц.

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

CREATE SEQUENCE document_numbers START WITH 1000;

CREATE TABLE invoices (
    invoice_id INTEGER DEFAULT NEXT VALUE FOR document_numbers PRIMARY KEY
);

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

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

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

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

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

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

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

Гарантирует ли identity отсутствие пропусков в ключах?

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

Можно ли безопасно использовать одну последовательность для нескольких таблиц?

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

Что произойдёт с генератором при удалении таблицы с identity-столбцом?

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