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

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

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

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

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

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

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

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

Есть и технические риски. Поддержка ссылок на уникальные индексы, частичных индексов, выражений и поведение при значениях NULL различаются между СУБД, поэтому решение может оказаться непереносимым или несовместимым с внешним ключом.

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

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

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

CREATE TABLE customer (
    customer_id INTEGER PRIMARY KEY,
    email VARCHAR(320) NOT NULL,
    CONSTRAINT uq_customer_email UNIQUE (email)
);

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

Выбор зависит от намерения:

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

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

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

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

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

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

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

Может ли уникальный индекс полностью заменить UNIQUE?

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

Почему СУБД часто создаёт индекс после объявления UNIQUE?

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

Можно ли внешним ключом ссылаться на любое уникальное выражение или частичный уникальный индекс?

Нет, универсального правила «любой уникальный индекс подходит» нет. Внешний ключ должен ссылаться на объект, который конкретная СУБД признаёт подходящим уникальным ключом; выражения и частичные индексы часто не удовлетворяют этому требованию, поскольку их уникальность может действовать не для всех строк. Такое решение нужно проверять по документации используемой СУБД и обычно моделировать явным UNIQUE-ограничением на столбцах.