Det er almindeligt aftalt, at primærnøgler skal være uforanderlige (eller så stabile som muligt, da uforanderlighed ikke kan håndhæves i DB). Selvom der ikke er noget, der forhindrer dig i at opdatere en primær nøgle (undtagen integritetsbegrænsning), er det måske ikke en god idé:
Fra et præstationssynspunkt:
- Du skal opdatere alle fremmednøgler, der refererer til den opdaterede nøgle. En enkelt opdatering kan føre til opdatering af potentielt mange tabeller/rækker.
- Hvis fremmednøglerne er uindekseret (!!), bliver du nødt til at opretholde en lås på børnebordet for at sikre integritet. Oracle holder kun låsen i kort tid, men det er alligevel skræmmende.
- Hvis dine fremmednøgler er indekseret (som de skal være), vil opdateringen føre til opdatering af indekset (delete+insert i indeksstrukturen), dette er generelt dyrere end selve opdateringen af basistabellen.
- I ORGANISATION INDEX-tabeller (i andre RDBMS, se klyngede primærnøgle), er rækkerne fysisk sorteret efter den primære nøgle. En logisk opdatering vil resultere i en fysisk slet+indsæt (dyrere)
Andre overvejelser:
- Hvis der refereres til denne nøgle i et eksternt system (applikationscache, en anden DB, eksport...), vil referencen blive ødelagt ved opdatering.
- derudover understøtter nogle RDBMS ikke CASCADE UPDATE, især Oracle.
Som konklusion, under design, er det generelt sikrere at bruge en surrogatnøgle i stedet for en naturlig primærnøgle, der formodes ikke at ændre sig -- men som i sidste ende skal opdateres på grund af ændrede krav eller endda dataindtastningsfejl.
Hvis du absolut skal opdatere en primær nøgle med børnetabel, se dette indlæg af Tom Kyte for en løsning.