Es besteht allgemein Einigkeit darüber, dass Primärschlüssel unveränderlich sein sollten (oder so stabil wie möglich, da Unveränderlichkeit in der DB nicht erzwungen werden kann). Es gibt zwar nichts, was Sie daran hindert, einen Primärschlüssel zu aktualisieren (außer Integritätsbeschränkung), aber es ist möglicherweise keine gute Idee:
Aus Leistungssicht:
- Sie müssen alle Fremdschlüssel aktualisieren, die auf den aktualisierten Schlüssel verweisen. Eine einzelne Aktualisierung kann zur Aktualisierung potenziell vieler Tabellen/Zeilen führen.
- Wenn die Fremdschlüssel nicht indiziert sind (!!), müssen Sie eine Sperre für die Kindertabelle aufrechterhalten, um die Integrität sicherzustellen. Oracle wird die Sperre nur für kurze Zeit halten, aber das ist trotzdem beängstigend.
- Wenn Ihre Fremdschlüssel indiziert sind (wie sie sein sollten), führt die Aktualisierung zur Aktualisierung des Index (Löschen+Einfügen in die Indexstruktur), dies ist im Allgemeinen teurer als die eigentliche Aktualisierung der Basistabelle.
- In ORGANIZATION INDEX-Tabellen (in anderen RDBMS, siehe Clustered Primary Key) werden die Zeilen physikalisch nach dem Primärschlüssel sortiert. Eine logische Aktualisierung führt zu einem physischen Löschen+Einfügen (teurer)
Weitere Überlegungen:
- Wenn auf diesen Schlüssel in einem externen System verwiesen wird (Anwendungs-Cache, eine andere DB, Export...), wird die Referenz bei der Aktualisierung unterbrochen.
- Außerdem unterstützen einige RDBMS CASCADE UPDATE nicht, insbesondere Oracle.
Zusammenfassend lässt sich sagen, dass es während des Entwurfs im Allgemeinen sicherer ist, einen Ersatzschlüssel anstelle eines natürlichen Primärschlüssels zu verwenden, der sich nicht ändern soll – aber möglicherweise aufgrund geänderter Anforderungen oder sogar Dateneingabefehler aktualisiert werden muss.
Wenn Sie unbedingt einen Primärschlüssel mit untergeordneter Tabelle aktualisieren müssen, finden Sie in diesem Beitrag von Tom Kyte eine Lösung.
