Что произойдёт при создании внешнего ключа, если таблица, на которую он ссылается, ещё не существует?

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

Создание внешнего ключа завершится ошибкой: таблица и обычно указанный ключ, на который идёт ссылка, должны существовать в момент определения ограничения. Рабочий порядок — сначала создать родительскую таблицу, затем дочернюю с внешним ключом либо добавить ограничение позже через ALTER TABLE.

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

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

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

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

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

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

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

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

CREATE TABLE customers (
    customer_id INTEGER PRIMARY KEY
);

CREATE TABLE orders (
    order_id INTEGER PRIMARY KEY,
    customer_id INTEGER,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

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

Если дочерняя таблица уже создана, ограничение можно добавить отдельным DDL-оператором. Но существующие строки будут проверены при добавлении ограничения; при наличии «осиротевших» значений операция завершится ошибкой, и данные сначала придётся исправить.

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

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

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

В миграции интернет-магазина разработчик разместил создание заказов раньше создания клиентов, потому что ориентировался на порядок экранов приложения. Развёртывание остановилось на DDL, а команда временно убрала внешний ключ, чтобы «пропустить» миграцию.

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

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

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

1. Можно ли создать дочернюю таблицу раньше родительской, если внешний ключ добавить позже?

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

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

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

3. Что произойдёт при добавлении внешнего ключа к уже заполненной дочерней таблице?

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