Non può funzionare in questo modo. Considera:
- programma uno, apri una transazione e la inserisci in una tabella FOO che ha una chiave primaria autoinc (arbitrariamente, diciamo che ottiene 557 per il suo valore chiave).
- Il programma due parte, apre una transazione e la inserisce nella tabella FOO ottenendo 558.
- Programma due inserti nella tabella BAR che ha una colonna che è una chiave esterna per FOO. Quindi ora il 558 si trova sia in FOO che in BAR.
- Il programma due ora esegue il commit.
- Il programma tre si avvia e genera un rapporto dalla tabella FOO. Il record 558 viene stampato.
- Dopodiché, il programma uno torna indietro.
In che modo il database recupera il valore 557? Va in FOO e decrementa tutte le altre chiavi primarie maggiori di 557? Come risolve la BAR? Come si cancella il 558 stampato sull'output del programma tre rapporti?
Anche i numeri di sequenza di Oracle sono indipendenti dalle transazioni per lo stesso motivo.
Se riesci a risolvere questo problema in tempo costante, sono sicuro che puoi guadagnare un sacco di soldi nel campo del database.
Ora, se hai il requisito che il tuo campo di incremento automatico non abbia mai spazi vuoti (ad esempio per scopi di controllo). Quindi non puoi ripristinare le tue transazioni. Invece devi avere un flag di stato nei tuoi record. Al primo inserimento, lo stato del record è "Incompleto", quindi inizi la transazione, fai il tuo lavoro e aggiorni lo stato per "competizione" (o qualunque cosa ti serva). Quindi, quando ti impegni, il record è attivo. Se la transazione viene annullata, il record incompleto è ancora lì per il controllo. Questo ti causerà molti altri mal di testa, ma è un modo per gestire gli audit trail.
