nicht angemeldet
Hi Leute
Gibt es dagegen wichtige Einwände?
nein.
Ganz bestimmt gibt es diese! Einzige Ausnahme sind Daten, die per se schon einen einzigartigen Wert beinhalten, der sich als Primary Key verwenden lässt.
Wie Ilja bereits gesagt hat, ist es ein nicht zu unterschätzender Mehraufwand einerseits für dich als Programmierer, andererseits für das DBMS, da du ja vor jeder Vergabe eines neuen Keys prüfen musst, ob dieser nicht bereits existiert (-> Performance).
Wenn du den Key nicht fortlaufend durchnummerierst, dann verschenkst du wertvolle Key-Bereiche, die nachträglich nur schwer ausgemacht und aufgefüllt werden können.
Ich empfehle dir, für jede Tabelle eine Autoincrement-ID-Spalte zu erstellen. Versehentliches Löschen sollte es in einem produktiven Datentopf nicht geben: Entweder du stellst ein Backup wieder her oder du fügst den Datensatz halt unter einer neuen ID wieder ein.
Bessere DBMSe stellen dir Mechanismen zur Verfügung um die referentielle Integrität sicher zu stellen (-> Handbuch). Mein MS SQL Server reklamiert beispielsweise, wenn ich einen verlinkten Datensatz löschen will. Ich kann ihm aber auch sagen, dass er die verknüpften Daten auch gleich löschen soll.
In dem von dir beschriebenen Fall würde ich mir die alte ID merken, den Datensatz mit einer neuen ID erstellen, alle mit der alten ID verknüpften Datensätze suchen und diese mit der neuen ID verknüpfen.
Gruss & HTH
Tom2