Общепринято, что первичные ключи должны быть неизменяемыми (или настолько стабильными, насколько это возможно , поскольку неизменяемость не может быть применена в БД).Хотя ничто не помешает вам обновить первичный ключ (кроме ограничения целостности), это может быть не очень хорошей идеей:
С точки зрения производительности:
- Выпотребуется обновить все внешние ключи, которые ссылаются на обновленный ключ.Одно обновление может привести к обновлению потенциально большого количества таблиц / строк.
- Если внешние ключи неиндексированы (!!), вам придется поддерживать блокировку дочерней таблицы для обеспечения целостности.Oracle будет удерживать блокировку только в течение короткого времени, но, тем не менее, это страшно.
- Если ваши внешние ключи проиндексированы (как и должно быть), обновление приведет к обновлению индекса (delete + insertв структуре индекса), это, как правило, дороже, чем фактическое обновление базовой таблицы.
- В таблицах INDGANIZATION INDEX (в других СУБД см. кластерный первичный ключ) строки физически сортируются по первичному ключу,Логическое обновление приведет к физическому удалению + вставке (более дорогое)
Другие соображения:
- Если на этот ключ ссылается какая-либо внешняя система (кэш приложения, другойБД, экспорт ...), ссылка будет прервана после обновления.
- дополнительно, некоторые СУБД не поддерживают CASCADE UPDATE, в частности Oracle .
В заключение, при проектировании, как правило, безопаснее использовать суррогатный ключ вместо естественного первичного ключа, который, как предполагается, не изменяется, но, возможно, в конечном итоге потребуется обновить из-за изменившихся требований или даже ошибки ввода данных.
Если вам абсолютно необходимо обновить первичный ключ с помощью таблицы потомков, см. этот пост Тома Кайта (Tom Kyte) для решения .