> 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.
Pero incluso siendo este el caso, yo no usaría al número de factura
como la llave primaria. Generaría en todo caso algo como:
CREATE TABLE factura (
id SERIAL PRIMARY KEY,
factura integer NOT NULL DEFAULT siguiente_factura(),
otro_campo blah blah
);
Claro, poniendo la lógica en cuestión bajo siguiente_factura(), y
creándole un bonito índice para el rendimiento. Sí, sé que el número
de factura no _debe_ cambiar, pero... Bueno, todos los atributos que
un humano pueda tocar son malas opciones para una llave primaria. Y no
sé cómo sea en sus países, pero en México tú no puedes imprimir el
número de factura - tiene que venir pre-impreso por un impresor
autorizado. Eso sólo significa que el número de factura se tiene que
capturar una vez teniendo el papelito impreso (o listo en la
impresora).
Saludos,
--
Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
TIP 7: no olvides aumentar la configuración del "free space map"
No comments:
Post a Comment