Как сказал Ларри, при обновлении Cascade будет работать, однако это может вызвать серьезные проблемы в рабочей базе данных, и большинство dbas не слишком рады тому, что вы можете использовать его. Например, предположим, что у вас есть клиент, который меняет название своей компании (и это PK), и в разных таблицах есть два миллиона связанных записей. При UPDATE Cascade выполнит все обновления в одной транзакции, которые могут заблокировать ваши основные таблицы на несколько часов. Это одна из причин, почему очень плохая идея иметь PK, который нужно будет заменить. Триггер был бы таким же плохим, и если его неправильно написать, он мог бы быть намного хуже.
Если вы вносите изменения в сохраненный процесс, вы можете поместить каждую часть в отдельную транзакцию, так что, по крайней мере, вы не блокируете все. Вы также можете обновлять записи в пакетах, так что если у вас есть миллион записей для обновления в таблице, вы можете делать их небольшими партиями, которые будут работать быстрее и иметь меньше блокировок. Лучший способ сделать это - создать новую запись в первичной таблице с новым PK, а затем переместить старые записи в новую в пакетном режиме, а затем удалить старую запись после перемещения всех связанных записей. Если вы делаете такие вещи, лучше всего иметь таблицы аудита, чтобы вы могли легко восстановить данные, если возникнет проблема, поскольку вы захотите сделать это в нескольких транзакциях, чтобы избежать блокировки всей базы данных. Теперь это сложнее поддерживать, вы должны помнить, чтобы добавить в процесс, когда вы добавляете FK (но вы также должны помнить, что нужно делать и с UPDATE CASCADE). С другой стороны, если он выходит из строя из-за проблемы с новым FK, это легко исправить, вы точно знаете, в чем проблема, и можете легко внести изменения в продукт относительно быстро.
Нет простых решений этой проблемы, потому что основная проблема - плохой дизайн. Вам нужно будет просмотреть все «за» и «против» всех решений (я бы отбросил идею триггера, так как Cascade Update будет работать лучше и будет меньше подвержен ошибкам), и решу, что работает лучше всего в вашем случае. Помните, что целостность данных и производительность имеют решающее значение для корпоративных баз данных и могут быть важнее, чем удобство обслуживания (я знаю, это ересь).