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

Каскадное обновление автоматически заменяет во всех зависимых строках значения внешнего ключа, соответствующие изменённому родительскому ключу. Благодаря этому дочерние строки продолжают ссылаться на существующую родительскую строку, а не становятся «сиротами».

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

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

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

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

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

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

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

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

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

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

Минимальный пример:

CREATE TABLE customer (
    customer_id INTEGER PRIMARY KEY
);

CREATE TABLE orders (
    order_id INTEGER PRIMARY KEY,
    customer_id INTEGER NOT NULL,
    FOREIGN KEY (customer_id)
        REFERENCES customer(customer_id)
        ON UPDATE CASCADE
);

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

ON UPDATE CASCADE отличается от ON DELETE CASCADE. Первый распространяет изменение значения ключа, второй удаляет зависимые строки при удалении родительской строки. Эти действия настраиваются независимо; наличие одного не означает наличие другого.

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

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

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

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

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

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

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

1. Что произойдёт с дочерними строками внутри транзакции во время каскадного обновления?

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

2. Заменяет ли каскадное обновление обычную транзакцию приложения?

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

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

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