Arbeiten ohne autoincrement

[Aristo]

Hi,

autoincrement ist prima aus Sicht eines DBMS, aber nicht unbedingt aus Entwicklersicht. So kann MySQL keine versehentlich gelöschten Datensätze mehr unter der gleichen ID wiederherstellen. Daher die Frage: ist es eigentlich gefährlich, mit selbst generierten IDs zu arbeiten anstelle von autoincrement? Also zum Beispiel beim Einfügen von Datensätzen (die Daten kommen aus einem HTML-Formular) einen ID-Wert aus Timestamp plus Prozess-ID des Apache/PHP-Prozesses zu generieren. Wichtig ist doch eigentlich nur, dass alle generierten Werte unique sind, möglichst numerisch und dass die Spalte einen Primary Key hat. Gibt es dagegen wichtige Einwände?

Gruß Aristo

[Andreas Dölling]

Hallo,

Gibt es dagegen wichtige Einwände?

nein.

Ciao,
Andreas

[Tom2 (der authentifizierte)]

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

[Ilja]

yo,

Wichtig ist doch eigentlich nur, dass alle generierten Werte unique sind, möglichst numerisch und dass die Spalte einen Primary Key hat. Gibt es dagegen wichtige Einwände?

du wiederlegst dich ja selber. der autoincrementwert erfüllt genau die kriterien, die ein pk braucht nämlich unique und not null. ob durch löschen dabei lücken entstehen ist schnuppe und kein nachteil. dagegen würde also der mehraufwand stehen, weil es gar kein handlungsbedarf gibt.

Ilja

[wahsaga]

hi,

autoincrement ist prima aus Sicht eines DBMS, aber nicht unbedingt aus Entwicklersicht. So kann MySQL keine versehentlich gelöschten Datensätze mehr unter der gleichen ID wiederherstellen.

Wie meinst du das?
Natürlich stellt MySQL nicht selbst irgendetwas wieder her?

Aber den gewünschten Wert für die autoincrement-ID gezielt bei einem INSERT anzugeben, ist problemlos möglich, wenn dieser Wert "frei" ist.

gruß,
wahsaga

[Aristo]

Hi wahsaga,

Aber den gewünschten Wert für die autoincrement-ID gezielt bei einem INSERT anzugeben, ist problemlos möglich, wenn dieser Wert "frei" ist.

Danke, das war für mich ein wichtiger Hinweis. Irgendwie dachte ich (wohl dummerweise) immer, das geht nicht, aber habs jetzt noch mal ausprobiert. Geht wirklich. Dann kann ich mein Vorhaben denke ich auch mit autoincrement lösen, danke!

Gruß Aristo

[Ilja]

yo,

Geht wirklich. Dann kann ich mein Vorhaben denke ich auch mit autoincrement lösen, danke!

ich sehe da schon unheil nahen....lücken können, sollten aber erst gar nicht gefüllt werden.

Ilja

[Cheatah]

Hi,

autoincrement ist prima aus Sicht eines DBMS, aber nicht unbedingt aus Entwicklersicht.

wieso nicht?

Cheatah