nicht angemeldet
Hallo,
Es funktioniert so zwar wunderbar, aber ich kann mir nicht vorstellen, dass man in der Praxis so vorgeht. Vor allem könnte es zwar ziemlich unwahrscheinlich, aber theoretisch doch möglich sein, dass gleichzeitig zwei Clients zur gleichen Zeit auf den Server zugreifen und zwei neue Personen mit gleichem Geburtsdatum und Namen eingefügt werden. Und durch die Tatsache, dass es mehrere INSERT-Anweisungen sind, zwischen denen ja eine gewisse Pause ist, könnten die Personen-IDs durcheinander gebracht werden wodurch die Adresse1, die zu Person Max Mustermann1 gehört, plötzlich dem Max Mustermann2 zugewiesen wird, da in der Zwischenzeit der Zähler wieder um eins weitegezählt hat.
Damit hier keine Race-Condition für die Schlüssel entsteht, bieten die Datenbanksysteme normalerweise sogenannte Autowerte an. Das sind numerische Schlüssel, die vom DBMS beim Insert eines Datensatzes automatisch ermittelt und für jede Connection separat geführt werden. Meistens sind dies Auto-Increment-Keys. Sie sind natürlich UNIQUE und daher gleichzeitig Primary Key des Datensatzes.
Dadurch, dass das DBMS sich darum kümmert, sind der Insert und die Schlüsselvergabe nach außen atomar gebunden und es gibt keine lost keys, da das System nur einen Schlüssel generiert, wenn der DS tatsächlich eingefügt wird.
Man muss also nach dem Insert zuerst fragen, ob der Insert überhaupt geklappt hat (also nicht gegen Contraints verstoßen hat) und dann den Schlüssel (z.B. Last_Insert_Id) abholen. Den kann man dann als Foreign Key für die nächste Tabelle verwenden.
Insgesamt sollte man natürlich über den gesamten Vorgang der Insert-Kette eine transaktion legen, wenn das DBMS dies zulässt, damit die Integrität auf jeden Fall wiederhergestellt werden kann, wenn etwas schief gegangen sein sollte.
LG
Chris©