--- El jue 17-jul-08, Alvaro Herrera <[EMAIL PROTECTED]> escribió:

> De: Alvaro Herrera <[EMAIL PROTECTED]>
> Asunto: Re: [pgsql-es-ayuda] como lograr campo consecutivo sin fallar ?
> A: "Roberto Rodríguez Pino" <[EMAIL PROTECTED]>
> Cc: [email protected]
> Fecha: jueves, 17 julio, 2008, 2:33 pm
> Roberto Rodríguez Pino escribió:
> 
> > Yo tengo un problema similar. Se salta el correlativo
> en caso de que
> > haya habido un fallo en la inserción.
> > Yo estoy ocupando jdbc. Necesitaba hacer 2
> inserciones, donde la
> > segunda dependia de la primera... pero si habia algun
> problema en la
> > segunda, la primera no debia llevarse a cabo. Para lo
> cual aplicaba un
> > rollback.
> > Pero asi y todo se seguian "quemando"  los
> identificadores de la
> > secuencia. Despues revise la cantidad de numeros
> disponbles y era una
> > suma considerable, asi que no le di mucha importancia
> (en mi problema,
> > me indiferente que se salte de un 3 a un 6)... pero
> igual me quedo la
> > duda de como se podria solucionar esto.
> 
> Claro, pero para hacer una asignación numérica que
> "no falle" no puedes
> usar una secuencia.  Tienes que bloquear la tabla y hacer
> la inserción
> del siguiente número disponible.  Esto obviamente tiene
> menor
> rendimiento (solo puede haber un proceso insertando a la
> vez), pero te
> aseguras que no habrá agujeros en la numeración.
> 
> Dado que la generación de facturas no es una cosa
> terriblemente
> frecuente, el menor rendimiento no debería ser un
> problema.  Cada
> transacción debería tomar menos de un segundo de todas
> maneras.  Un
> usuario que tiene que esperar un segundo más, no se da ni
> cuenta de la
> diferencia.
> 
> -- 
> Alvaro Herrera                       
> http://www.advogato.org/person/alvherre
> "Si un desconocido se acerca y te regala un CD de
> Ubuntu ...
>                                      Eso es ...  Eau de
> Tux"
> --
> TIP 6: ¿Has buscado en los archivos de nuestra lista de
> correo?
>               
> http://archives.postgresql.org/pgsql-es-ayuda
Particularmente tengo una tabla con codigo numerador y numero y otra con 
diferentes tipos de documentos para las diferentes cajas de la empresa, 
entonces un tipo de documento corresponde a un numero de caja y la caja a su 
vez a un local, luego cada tipo de documento tiene un id_numerador unico, pero 
un numerador podria o no relacionarse a dos tipos de documentos similares, por 
ejemplo remito a central o remito a deposito podrian compartir numeracion o 
tenerla independiente.

Un documento en su cabezal tiene un campo id_cabezal serial que lo relaciona a 
las lineas, pero tiene otro campo con serie y numero, este numero se incrementa 
desde la aplicacion sumandole 1, cada vez que se manda un documento a emitir, 
esto lo hace consultando un views con rules que me permiten modificarlo desde 
la aplicacion, en ese momento el equipo cliente bloquea la tabla, view, estoy 
en una empresa que hace 1000 documentos por dia con 6 equipos en el mostrador y 
no hemos tenido problemas ni de performance ni defectos en la numeracion.

Comento esto por que se ha realizado esta pregunta antes y la forma que propone 
Alvaro me parece la mejor, no usar seriales para cosas que identifiquen 
documentos, describo mi experiencia, puesto que en otra aplicacion que le hice 
a un amigo para emitir recibos, resolvia hacerlo por un serial, si se llega a 
equivocar lo tengo que emitir igual para que lo anule asi no salteo ningun 
numero, algo muy desprolijo para un amigo que no podia pagarme hacer algo 
decente, pero los dos sabemos que eso es una desprolijidad que no debimos haber 
implementado, pero se ahorro en software gastando mas papel.

Atte.
Gabriel Colina


      
____________________________________________________________________________________
Yahoo! MTV Blog & Rock &gt;¡Cuéntanos tu historia, inspira una canción y gánate 
un viaje a los Premios MTV! Participa aquí http://mtvla.yahoo.com/
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
               http://archives.postgresql.org/pgsql-es-ayuda

Responder a