Sådan kan det ikke fungere. Overvej:
- program et, du åbner en transaktion og indsætter i en tabel FOO, som har en autoinc primær nøgle (vilkårligt siger vi, at den får 557 for sin nøgleværdi).
- Program to starter, det åbner en transaktion og indsætter i tabel FOO og får 558.
- Programmer to indsættelser i tabel BAR, som har en kolonne, som er en fremmednøgle til FOO. Så nu er 558 placeret i både FOO og BAR.
- Program to forpligtes nu.
- Program tre starter og genererer en rapport fra tabel FOO. 558-posten udskrives.
- Derefter ruller program et tilbage.
Hvordan genvinder databasen 557-værdien? Går den ind i FOO og formindsker alle de andre primære nøgler større end 557? Hvordan løser det BAR? Hvordan sletter det de 558, der er trykt på rapportprogrammets tre output?
Oracles sekvensnumre er også uafhængige af transaktioner af samme årsag.
Hvis du kan løse dette problem på konstant tid, er jeg sikker på, at du kan tjene mange penge på databasefeltet.
Hvis du nu har et krav om, at dit automatiske inkrementfelt aldrig har huller (f.eks. til revisionsformål). Så kan du ikke rulle dine transaktioner tilbage. I stedet skal du have et statusflag på dine poster. Ved første indsættelse er postens status "Ufuldstændig", så starter du transaktionen, gør dit arbejde og opdaterer status til "konkurrerende" (eller hvad du nu har brug for). Når du så forpligter dig, er pladen live. Hvis transaktionen ruller tilbage, er den ufuldstændige post stadig der til revision. Dette vil give dig mange andre hovedpine, men er en måde at håndtere revisionsspor på.