Je obecně dohodnuto, že primární klíče by měly být neměnné (nebo co nejstabilnější, protože neměnnost nelze v DB vynutit). I když vám nic nebrání v aktualizaci primárního klíče (kromě omezení integrity), nemusí to být dobrý nápad:
Z hlediska výkonu:
- Budete muset aktualizovat všechny cizí klíče, které odkazují na aktualizovaný klíč. Jediná aktualizace může vést k aktualizaci potenciálně mnoha tabulek/řádků.
- Jsou-li cizí klíče neindexované (!!), budete muset zachovat zámek na podřízeném stole, aby byla zajištěna integrita. Oracle podrží zámek pouze na krátkou dobu, ale přesto je to děsivé.
- Pokud jsou vaše cizí klíče indexovány (jak by měly být), aktualizace povede k aktualizaci indexu (smazat+vložit do struktury indexu), což je obecně dražší než vlastní aktualizace základní tabulky.
- V tabulkách ORGANIZATION INDEX (v jiných RDBMS, viz seskupený primární klíč) jsou řádky fyzicky seřazeny podle primárního klíče. Logická aktualizace bude mít za následek fyzické odstranění+vložení (dražší)
Další úvahy:
- Pokud se na tento klíč odkazuje v jakémkoli externím systému (mezipaměť aplikace, jiná databáze, export...), bude odkaz po aktualizaci zrušen.
- Některé RDBMS navíc nepodporují CASCADE UPDATE, zejména Oracle.
Závěrem lze říci, že během návrhu je obecně bezpečnější použít náhradní klíč namísto přirozeného primárního klíče, o kterém se předpokládá, že se nemění – ale může být nakonec nutné aktualizovat kvůli změněným požadavkům nebo dokonce chybě při zadávání dat.
Pokud nezbytně musíte aktualizovat primární klíč s tabulkou dětí, řešení najdete v tomto příspěvku Toma Kytea.