Общоприето е, че първичните ключове трябва да бъдат неизменни (или възможно най-стабилни, тъй като неизменимостта не може да бъде наложена в DB). Въпреки че няма нищо, което да ви попречи да актуализирате първичен ключ (с изключение на ограничението за целостта), това може да не е добра идея:
От гледна точка на производителността:
- Ще трябва да актуализирате всички външни ключове, които препращат към актуализирания ключ. Една актуализация може да доведе до актуализиране на потенциално много таблици/редове.
- Ако външните ключове са неиндексирани (!!), ще трябва да поддържате заключване на дъщерната таблица, за да гарантирате целостта. Oracle ще задържи ключалката само за кратко време, но все пак това е страшно.
- Ако външните ви ключове са индексирани (както трябва да бъдат), актуализацията ще доведе до актуализиране на индекса (изтриване+вмъкване в структурата на индекса), това обикновено е по-скъпо от действителната актуализация на основната таблица.
- В таблиците ORGANIZATION INDEX (в други RDBMS, вижте клъстериран първичен ключ), редовете са физически сортирани по първичния ключ. Логическата актуализация ще доведе до физическо изтриване+вмъкване (по-скъпо)
Други съображения:
- Ако този ключ е посочен във външна система (кеш на приложението, друга DB, експортиране...), препратката ще бъде прекъсната при актуализиране.
- в допълнение, някои RDBMS не поддържат CASCADE UPDATE, по-специално Oracle.
В заключение, по време на проектирането обикновено е по-безопасно да се използва сурогатен ключ вместо естествен първичен ключ, за който се предполага, че не се променя – но в крайна сметка може да се наложи да бъде актуализиран поради променени изисквания или дори грешка при въвеждане на данни.
Ако абсолютно трябва да актуализирате първичен ключ с дъщерна таблица, вижте тази публикация от Tom Kyte за решение.
