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

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

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

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

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

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

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

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

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

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

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

Естественный идентификатор при этом хранится отдельно. Если он должен быть уникальным, для него задают ограничение UNIQUE; если он обязателен — дополнительно NOT NULL. Так сохраняются оба свойства: стабильные ссылки на заказ и контроль бизнес-правила.

CREATE TABLE orders (
    order_id BIGINT PRIMARY KEY,
    external_number VARCHAR(40) NOT NULL UNIQUE,
    customer_id BIGINT NOT NULL
);

CREATE TABLE order_items (
    order_id BIGINT NOT NULL,
    product_id BIGINT NOT NULL,
    quantity INTEGER NOT NULL,
    PRIMARY KEY (order_id, product_id),
    FOREIGN KEY (order_id) REFERENCES orders(order_id)
);

В примере изменение external_number не затрагивает строки order_items: внешняя связь построена по стабильному order_id. Ограничение уникальности всё равно не позволяет двум заказам иметь один внешний номер.

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

Каскадное обновление внешних ключей может уменьшить риск частичного изменения внутри одной базы, но не решает проблему внешних систем и больших объёмов данных. Поэтому ON UPDATE CASCADE не превращает изменяемый естественный ключ в хороший идентификатор сущности.

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

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

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

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

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

1. Достаточно ли суррогатного ключа без уникальности естественного идентификатора?

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

2. Всегда ли изменение первичного ключа запрещено?

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

3. Чем стабильный суррогатный ключ отличается от естественного ключа с редко меняющимся значением?

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