Autoincremento en Oracle 10g sin usar secuencia

Necesito simular un auto incremento en una base de datos. Ya probé haciéndolo con una secuencia y un trigger, pero no me gusta que la secuencia se incremente aún cuando ocurre un rollback.
Tengo la siguiente porción de código, pero no estoy seguro de cómo se comportará con la concurrencia.
contador:=0;
SELECT NVL(MAX(id_empleado),0) +1 INTO contador
FROM EMPLEADO;
:NEW.id_empleado:=contador;
¿Utilizo el código anterior? O ¿Existe otro método mejor para simular el autoincremento?

1 respuesta

Respuesta
No hay una muy buena solución para lo que te refieres. Es decir, un entorno 'gap free' (una secuencia sin vacíos) y con concurrente.
Con tu aproximación, tampoco puedes asegurar que no hayan vacíos, ya que si acceden 2 personas a la vez, incluso podrían tener un mismo número y provocar errores. Tendrías que bloquear la select hasta que hicieras un commit, con lo que la concurrencia en ese caso sería 0.
La pregunta a hacer es, ¿realmente es necesario que no haya ningún hueco en la secuencia? ¿Por qué?
La cuestión es que por auditoría no puedo tener saltos puesto que se pensaría que se borró un registro. Aunque ya tengo un trigger que me impide borrar datos, las personas que hacen auditoría no son informáticos y no entienden que en la secuencia pueden haber saltos.
De cualquier forma, lo que he hecho es bloquear la tabla en el insert para que nadie más ingrese datos. De esta manera, se crea una pseudo-cola en caso de que hubiera más de un usuario intentando ingresar datos.
Lo que tengo es esto:
IF INSERTING THEN
LOCK TABLE mi_tabla IN EXCLUSIVE MODE;
contador:=0;
SELECT NVL(MAX(IdColumna),0) +1 INTO contador FROM mi_tabla;
:New.IdColumna:=contador;
Esto, siguiendo el manual "b14220 - Oracle® Database Concepts 10g Release 2"
De cualquier forma, gracias por responder.
Me parece que la gente que hace la auditoría se tendría que informar que ya no hacen falta números de secuencia exactos (eso era cuando todo se hacía con documentos en papel) y que, además, con ello, están impidiendo que tu aplicación sea no-concurrente y poco escalable. Eso de que cuando alguien tenga que dar de alta un registro bloquee la tabla.. pufff..
Bueno, de todas maneras, si puedes cerrar la pregunta puntuando.
Pues por el momento se estima que serán alrededor de 50 registros por día. Así que espero que no haya problema.
Gracias por la respuesta.

Añade tu respuesta

Haz clic para o

Más respuestas relacionadas