nicht angemeldet
Tach!
Was aber wenn eine der 3 Teilquerys fehlschlägt? Dann kommt es zu Inkonsistenzen, die ich zu vermeiden versuche. Daher das autocommit(false) und die Überprüfung bei jeder der drei Teilquerys, ob sie nun valid durchgelaufen sind oder nicht. Wenn dem so war, führe ein commit() aus, wenn nicht rollback(). So weit ganz einleuchtend, oder?
Ja, so macht man das, wenn man ein transaktionsorientiertes DBMS zur Verfügung hat (unter MySQL nur mit InnoDB-Tabellen).
Mir ist dann nur eben aufgefallen, dass auch bei einem rollback() die AI ID immer weiter hochgezählt wird und da frage ich mich warum und was man dagegen tun kann.
Nichts, das ist, wie ich schon schrieb, ja auch nicht sinnvoll. Konkret wird schon bei jedem INSERT das zur Tabelle gehörige AI-Feld hochgezählt. Jedes INSERT braucht seine eigene eindeutige ID - über alle laufenden, erfolgreichen und abgebrochenen Transaktionen hinweg.
Wenn ihr irgendwelche Verbesserungsvorschläge habt, nur raus damit. Ich bin zwar kein Anfänger mehr, aber ich würde mich schon gerne verbessern.
Was definierst du in dem Fall als besser? Der Rollback-Fall wird hoffentlich nicht der Standard werden. Die paar "verlorenen" IDs spielen keine Rolle. Niemand wird die Vollständigkeit der IDs nachprüfen. Wichtig ist nur, dass die Beziehungen konsistent sind/bleiben, was man ja mit Foreign Key Constraints in InnoDB hinbekommen kann.
dedlfix.