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

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

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

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

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

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

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

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

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

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

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

Минимальный пример для СУБД, поддерживающей отложенные уникальные ограничения, например PostgreSQL:

CREATE TABLE task_order (
    task_id INTEGER PRIMARY KEY,
    position INTEGER,
    CONSTRAINT uq_task_position
        UNIQUE (position) DEFERRABLE INITIALLY DEFERRED
);

BEGIN;
UPDATE task_order SET position = 2 WHERE task_id = 1;
UPDATE task_order SET position = 1 WHERE task_id = 2;
COMMIT;

Внутри транзакции после первой команды значение 2 временно дублируется. При COMMIT база проверяет итоговое состояние; если позиции 1 и 2 распределены между строками без других конфликтов, транзакция завершается успешно.

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

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

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

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

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

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

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

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

Можно ли считать отложенное ограничение способом разрешить дубликаты навсегда?

Нет. Оно разрешает только временное нарушение в рамках незавершённой транзакции. Успешно зафиксированное состояние обязано удовлетворять уникальности; иначе фиксация завершается ошибкой или транзакция откатывается.

Чем отложенная уникальность отличается от проверки уникальности в приложении?

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

Почему не следует автоматически откладывать все ограничения?

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