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

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

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

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

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

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

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

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

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

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

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

Минимальная схема выглядит так:

CREATE TABLE customers (
    id integer PRIMARY KEY,
    email varchar(255) NOT NULL UNIQUE
);

CREATE TABLE orders (
    id integer PRIMARY KEY,
    customer_email varchar(255) NOT NULL,
    FOREIGN KEY (customer_email) REFERENCES customers(email)
);

Здесь заказ может ссылаться на email, потому что уникальность этого столбца гарантируется ограничением UNIQUE. Однако первичный ключ id обычно предпочтительнее: он стабилен, компактен, не зависит от бизнес-правил и реже меняется.

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

Следует учитывать действия при изменении и удалении родителя: RESTRICT или NO ACTION защищают от удаления используемой строки, CASCADE распространяет операцию, а SET NULL требует допуска NULL в дочернем столбце. Выбор зависит от смысла связи, а не только от удобства реализации.

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

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

В SaaS-системе заказ хранит имя клиента и пытается ссылаться на него как на родителя. Имена не уникальны: одинаковые имена могут существовать у разных клиентов, а изменение имени должно быть разрешено.

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

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

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

Достаточно ли индекса без ограничения уникальности для целевого столбца внешнего ключа?

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

Может ли внешний ключ содержать NULL?

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

Почему для составного внешнего ключа недостаточно совпадения одного столбца?

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