No puede funcionar de esa manera. Considere:
- programa uno, abre una transacción e inserta en una tabla FOO que tiene una clave principal autoinc (arbitrariamente, decimos que obtiene 557 por su valor de clave).
- El programa dos comienza, abre una transacción y se inserta en la tabla FOO obteniendo 558.
- Programe dos inserciones en la tabla BAR que tiene una columna que es una clave externa para FOO. Así que ahora el 558 está ubicado tanto en FOO como en BAR.
- El programa dos ahora se confirma.
- El programa tres se inicia y genera un informe a partir de la tabla FOO. Se imprime el registro 558.
- Después de eso, el programa uno retrocede.
¿Cómo recupera la base de datos el valor 557? ¿Entra en FOO y decrementa todas las demás claves primarias superiores a 557? ¿Cómo soluciona BAR? ¿Cómo borra el 558 impreso en la salida del programa tres del informe?
Los números de secuencia de Oracle también son independientes de las transacciones por la misma razón.
Si puede resolver este problema en tiempo constante, estoy seguro de que puede ganar mucho dinero en el campo de la base de datos.
Ahora, si tiene el requisito de que su campo de incremento automático nunca tenga espacios (por ejemplo, para fines de auditoría). Entonces no puede revertir sus transacciones. En su lugar, debe tener un indicador de estado en sus registros. En la primera inserción, el estado del registro es "Incompleto", luego inicia la transacción, hace su trabajo y actualiza el estado para "competir" (o lo que necesite). Luego, cuando te comprometes, el registro está en vivo. Si la transacción se revierte, el registro incompleto todavía está allí para su auditoría. Esto le causará muchos otros dolores de cabeza, pero es una forma de lidiar con los registros de auditoría.
