Hello Ilja,
Genau dieses Problem hatte ich mal bei einem früheren Arbeitgeber ... die von mysql_insert_id() zurückgegebene ID war zwar zu dem Zeitpunkt korrekt, während der Laufzeit des Skriptes wurden aber durch andere Nutzer weitere Einträge hinzugefügt, so dass hinterher ein ziemliches Durcheinander an IDs herrschte.
das ist kein problem, sondern so gewollt. mysql_insert_id ist von der jeweiligen session abhängig und nur so ist sie sinnvoll nutzbar. die funktion gibt mir die id meiner (meines Scriptes) letzten insert anweisung. ich will ja gar nicht wissen, welche id's andere benutzt haben, sondern nur meine ist interessant. auch der glaube, ich müsste immer den höchsten wert wissen führt nur in eine sackgasse. es spielt nämlich keine rolle, welchen wert ich nun gerade als id benutzte, er ist transparent. wichtig ist nur, dass die vergabe von pk-werten durch autoincrement oder von sequenzen session-gesichert ist. alles andere ist murks.
Ecki spielte hier auf den Designfehler an.
Er (das Programm) hat sich die _nächste_ ID besorgt, die er dann in Zukunft gerne benutzen wollte, indem er auf die vermeintlich letzte vergebene für die Tabelle eins draufgezählt hat.
Dabei hat er (oder seine Programmiererkollegen damals) nicht beachet, dass mysql_insert_id() nur die letzte von _ihm_ verwendete ID (also aus der Vergangenheit) zurückliefert. Das hast Du ja auch schon erwähnt.
Das Ganze beruht doch auf dem Irrglauben, dass MySQL die ID IMMER hochzählen würde. Hingegen ist es so designed, dass es lediglich irgendeine verfügbare ID aus dem Nummernvorrat zurückliefert.
Dass die nun meistens die nächstgrößere ist, möchte ich hier mal als Zufall bezeichnen.
Es handelt sich also in Wirklichkeit nicht um einen AUTOINCREMENT-Schlüssel, sondern nur um einen UNIQUE-AUTO-Key oder auch "Auto-Primaray-Key". Ein Unique Autoincrement Key arbeitet definitionsgemäß mit _verlorenen_ Schlüsseln in ordinaler Reihenfolge. Einmal vergeben, niemehr neu verwendet.
Darüber hinaus könnte man sich auch verlorene gestreute Schlüssel vorstellen. Sie werden zwar gestreut vergeben, aber "nie" ein zweites Mal. Dazu muss aber eine interne Tabelle erhalten bleiben, die die vergebenen, aber bereits wieder gelöschten Schlüssel speichert. Das ist vom Verfahren her recht mühselig und wird darum eigentlich nur selten gemacht (Bei Autonummern mit Zusatzbedingung der Wiederfreigabe nach X Jahren).
Die laufende Nummer ist klassisch gewachsen. Chaotische Verwaltung war in der Papierwelt nicht so gerne gesehen.
Es gibt aber auch DBMS, die die konsequente Inkrementierung des AutoIncrement-Keys verbindlich zusagen. Bei diesen kann der Schlüssel dann auch zur Ermittlung der Reihenfolge benutz werden, in der die Datensätze eingetragen wurden. Das muss man bei MySQL z.B. mit einem timestamp realisieren, der aber die Gefahr birgt, dass mehrere Datensätze denselben Timestamp bekommen. Eine Sekunde ist in einer Datenbank sehr lang ...................
MySQL hat hier meiner Meinung nach noch einen Designfehler.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)