Insbesondere wenn man mal mit einer Multiuserdatenbank arbeitet können Autoinc-Felder zu ganz bösen Fehlern führen.
Gerade da sorgen sie doch erst Recht für zuverlässige Indize-Felder?
Aber, man muß wenigstens den "richtigen" Master-Index wieder auslesen, wenn man dazu den Detail-Datensatz anlegen möche.
SELECT Max(ID) FROM Master
, nach dem Anlegen des Master-Datensatzes, ist da also totaler Mist, da dort natürlich die falsche ID gelesen werden kann, wenn zwischenzeitlich ein anderer User auch da was eingetragen hat.
Wenn man die IDs im Clienten bestimmt, dann weiß man zwar vor dem Anlegen des Master-Datensatzes, wie dessen ID sein wird und kann sie "sicher" für den Detail-Datensatz nutzen, aber dann
muß man womöglich im Clienten extra eine Fehlerbehandlung integrieren, da die Datenbank entsprechend reagiert, wenn zwischen dem
SELECT MAX
und dem
INSERT
ein anderer User schneller war und seinen Master-Datensatz anlegete und man nun selber natürlich eine doppelte ID anlegen möchte.
LAST_INSERT_ID ist doch Session an die Sessions gebunden?
Wenn ja, dann ist es an die eigene Verbindung gebunden und den darüber erstellten Datensatz, womit man dann seine ID bekommt, auch wenn jemand Anderes inzwischen gepostet hat.
Einige
DBMS kennen sowas wie
INSERT INTO table (id, value) VALUES (:id, :value) RETURNING id
, was quasi Folgendem entspricht, als "eine" zusammenhängende Abfrage.
SQL-Code:
INSERT INTO table (id, value) VALUES (:id, :value);
SELECT LAST_INSERT_ID();
SQLite aber anscheinend nicht.
Kennt SQLite eigentlich auch Referenzen?
Um gültige Werte der Master-IDs in der Detail-Tabelle sicherzustellen.