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

Нужно добавить внешний ключ: orders.customer_id должен ссылаться на customers.id. Тогда база данных сама запретит удалить или изменить клиента, если это нарушит ссылочную целостность, если явно не задано другое правило поведения.

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

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

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

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

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

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

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

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

Связь следует объявить внешним ключом:

CREATE TABLE customers (
    id BIGINT PRIMARY KEY
);

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    CONSTRAINT fk_orders_customer
        FOREIGN KEY (customer_id) REFERENCES customers(id)
);

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

Правило удаления выбирают по смыслу данных:

RESTRICT или NO ACTION — запретить удаление клиента, пока существуют заказы; подходит, когда заказы должны сохраняться;
CASCADE — удалить зависимые заказы вместе с клиентом; опасно для финансовых, юридических и аудиторских данных;
SET NULL — обнулить ссылку, но это требует nullable-поля и допустимо только при наличии понятия «заказ без клиента».

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

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

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

В CRM потребовалось удалить организацию, но её заказы и платежи должны были остаться для аудита. Рассматривались три варианта: удалять организацию каскадно, обнулять ссылки или полностью запретить удаление.

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

Результатом стала сохранность истории и гарантированное отсутствие заказов с несуществующей организацией. Компромисс — необходимость отдельно реализовать архивирование и фильтрацию неактивных организаций в прикладных сценариях.

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

Достаточно ли внешнего ключа, если клиент может быть удалён во время создания заказа?

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

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

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