So kann das nicht funktionieren. Bedenken Sie:
- Programm eins, Sie öffnen eine Transaktion und fügen FOO in eine Tabelle ein, die einen autoinc-Primärschlüssel hat (willkürlich sagen wir, dass es 557 für seinen Schlüsselwert erhält).
- Programm zwei startet, es öffnet eine Transaktion und fügt in die Tabelle FOO ein und erhält 558.
- Programmieren Sie zwei Einfügungen in die Tabelle BAR, die eine Spalte hat, die ein Fremdschlüssel für FOO ist. Jetzt befindet sich der 558 also sowohl in FOO als auch in BAR.
- Programm zwei wird jetzt übergeben.
- Programm drei startet und generiert einen Bericht aus der Tabelle FOO. Der 558-Datensatz wird gedruckt.
- Danach kehrt Programm eins zurück.
Wie fordert die Datenbank den Wert 557 zurück? Geht es in FOO und dekrementiert alle anderen Primärschlüssel größer als 557? Wie repariert es BAR? Wie löscht es die 558-Ausgabe des Berichtsprogramms drei?
Die Sequenznummern von Oracle sind aus dem gleichen Grund auch unabhängig von Transaktionen.
Wenn Sie dieses Problem in konstanter Zeit lösen können, bin ich sicher, dass Sie im Datenbankbereich viel Geld verdienen können.
Nun, wenn Sie eine Anforderung haben, dass Ihr Auto-Inkrement-Feld niemals Lücken hat (z. B. für Audit-Zwecke). Dann können Sie Ihre Transaktionen nicht rückgängig machen. Stattdessen müssen Sie ein Status-Flag in Ihren Aufzeichnungen haben. Beim ersten Einfügen ist der Status des Datensatzes "Unvollständig", dann starten Sie die Transaktion, erledigen Ihre Arbeit und aktualisieren den Status auf "Wettbewerb" (oder was auch immer Sie brauchen). Wenn Sie dann festschreiben, ist die Aufzeichnung live. Wenn die Transaktion zurückgesetzt wird, ist der unvollständige Datensatz immer noch für die Prüfung vorhanden. Dies wird Ihnen viele andere Kopfschmerzen bereiten, ist aber eine Möglichkeit, mit Audit-Trails umzugehen.
