Men is het er algemeen over eens dat primaire sleutels onveranderlijk moeten zijn (of zo stabiel mogelijk aangezien onveranderlijkheid niet kan worden afgedwongen in de DB). Hoewel er niets is dat u ervan weerhoudt een primaire sleutel bij te werken (behalve integriteitsbeperking), is het misschien geen goed idee:
Vanuit het oogpunt van prestaties:
- U moet alle externe sleutels bijwerken die verwijzen naar de bijgewerkte sleutel. Een enkele update kan leiden tot de update van mogelijk veel tabellen/rijen.
- Als de externe sleutels niet zijn geïndexeerd (!!), moet u een slot op de kindertafel handhaven om de integriteit te waarborgen. Oracle houdt het slot maar voor een korte tijd vast, maar toch is dit eng.
- Als uw externe sleutels zijn geïndexeerd (zoals ze zouden moeten zijn), zal de update leiden tot de update van de index (delete+insert in de indexstructuur), dit is over het algemeen duurder dan de daadwerkelijke update van de basistabel.
- In ORGANISATION INDEX-tabellen (zie in andere RDBMS, zie geclusterde primaire sleutel), zijn de rijen fysiek gesorteerd op de primaire sleutel. Een logische update zal resulteren in een fysieke delete+insert (duurder)
Andere overwegingen:
- Als naar deze sleutel wordt verwezen in een extern systeem (applicatiecache, een andere DB, export...), wordt de verwijzing verbroken bij de update.
- Bovendien bieden sommige RDBMS geen ondersteuning voor CASCADE UPDATE, met name Oracle niet.
Samenvattend:tijdens het ontwerp is het over het algemeen veiliger om een surrogaatsleutel te gebruiken in plaats van een natuurlijke primaire sleutel die niet zou moeten veranderen, maar die uiteindelijk mogelijk moet worden bijgewerkt vanwege gewijzigde vereisten of zelfs een fout bij het invoeren van gegevens.
Als je absoluut een primaire sleutel met kindertafel moet bijwerken, bekijk dan dit bericht van Tom Kyte voor een oplossing.