Hola chicos, hace siglos que no me conecto, pero aqui vuelvo!
Nuestra app principal es "muy multiusuario" y hacemos inserciones en masa algunas veces, y puede que curra desde dos pc simultaneamente, y ese problema lo tenemos 100% solucionado (bueno, digamos que 99%), os explico como:
1.- Necesitas un generador como dicen por arriba, una tabla adicional NO vale, porque al estar aislada en una transaccion no ve las otras simultaneas y puedes terminar con 2 id identicos, y usar el max(id+1) es lento y no te quita el problema de dos inserciones simultaneas chocando (te tocaria usar semaforos, pero ni eso te libra). Resumiendo: El generador no te lo quita nadie si quieres que funcione siempre.
2.- En lugar de pedirle numero al generador y usarlo en la insercion, que es valido pero trabajoso y tienes que ponerlo en tu codigo para caaadaaa insercion, enviamos la grabacion SIN poner nada en le id, es decir, llega con un null o con un cero.
3.- La tabla tiene un trigger before insert que, si el id esta vacio, pide al generador un id y se lo pone. Esto hace que si añades registros externamente, con dejar el id vacio todos entraran y no te cuasara problemas. Esto es muy importante si teneis opcion de importar datos desde otras apps que no sean vuestras.
4.- La insercion se llama con "returning id" si necesitas saber el id que te ha tocado, en nuestro caso eso lo usamos poco, pero por ejemplo, si tras grabar la factura tienes que añadir lineas de factura, usamos el returning siempre.
Los posibles problemas son muy pocos, pero hay dos o tres de los que realmente no suele hacer falta preocuparse:
1.- Si la grabacion falla por alguna restriccion, el id se ha consumido. Es decir, NUNCA asumas que el id 100 quiere decir que llevas 100 registros creados, ni que no van a haber saltos, es un id y no significa nada, solo se le pide ser unico, y eso lo cumple siempre.
2.- El generador se crea con un valor de cero, de forma que te dara un 1 al primer uso. Si tu tabla tiene valores previos, el generador se tiene que inicializar con el max(id) de tus datos actuales, de otra forma la grabacion fallaria por id duplicado (momento en el que puedes capturar el error y saber que tienes que actualizar tu generador si o si).
3.- Si dejas que ese id sea editable (en algunas fichas lo permitimos cuando ese id es "oficial") el usuario tendra la opcion de dejarlo en blanco (con lo que se usa el generador) o opner el algo, para rellenar huecos etc. En ese caso, el generador no avanza, con lo que o bien te arriesgas a que la siguiente grabacion falle por id duplicado, o bien en le trigger de insert, si te llega un id, comprebas que no supere al valor del generador y lo aumentas si hace falta.
Esto ultimo la verdad no deberia suceder, el id no debe ser editable, pon un id "interno" y otro "externo" editable, con sus dos generadores o lo que necesites, pero el "interno" mejor no visible, asi puedes luego permitir cambiar el id "visible" sin afectar a las conexiones entre tablas. Nosotros no seguimos siempre este consejo... pero bueno.
