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

DELETE удаляет выбранные строки, но не изменяет значения столбцов в остальных строках. Идентификатор — это атрибут конкретной строки, а не её текущая позиция в таблице, поэтому после удаления значения могут иметь пропуски.

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

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

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

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

Предположим, в таблице были идентификаторы 10, 11 и 12, а строку с идентификатором 11 удалили. Ожидание, что 12 автоматически станет 11, ошибочно: это изменило бы идентификатор уже существующей записи.

Такое перенумерование могло бы нарушить внешние ключи, кэшированные ссылки, журналы изменений и связи с внешними системами. Кроме того, последовательность или identity-генератор обычно не обязана возвращать ранее использованные значения.

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

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

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

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

CREATE TABLE accounts (
    account_id INTEGER GENERATED ALWAYS AS IDENTITY,
    name TEXT
);

INSERT INTO accounts (name)
VALUES ('А'), ('Б'), ('В');

DELETE FROM accounts
WHERE account_id = 2;

SELECT account_id, name
FROM accounts;

После удаления результат может содержать идентификаторы 1 и 3. Это нормальное состояние: идентификатор 3 продолжает обозначать ту же запись, которую он обозначал до удаления.

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

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

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

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

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

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

Можно ли считать пропуски в identity или sequence ошибкой?

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

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

Да. Плотный номер можно вычислить только для результата конкретного запроса с помощью оконной функции, например ROW_NUMBER(). Такой номер зависит от выбранного порядка и набора строк и не заменяет постоянный ключ.

Что нужно проверить перед ручным повторным использованием удалённого идентификатора?

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