Cita:
Empezado por Jack
Mi pregunta es si el update de la tabla stocks puede fallar al grabar la linea de venta e ir a actualizar el stock en los triggers after insert, before update, after delete de la linea de ventas. Esa es mi pregunta, la secuencia lógica del programa no me falla, lo he probado con muchos casos y calcula bien el stock ( al borrar, al modificar y al añadir lineas nuevas, lo hace bien, suma y resta cuando toca ).
El desajuste ocurre cuando hay muchos movimientos o cuando hay varios usuarios trabajando o por algún motivo que yo no logro comprender.
|
Ok, ya esto es otra cosa.
Puede fallar? Si.
Pero para eso son las transacciones. Existen diversos niveles de transaccion, con diversas garantias y promesas.
Puedes (y deberias) leer los docs al respecto:
http://www.firebirdsql.org/manual/is...nsactions.html
-------
Un problema con la forma como casi siempre se hace esto es que el proceso es *destructivo*, y una vez completo, es prácticamente imposible reconstruir lo que paso.
Sin embargo, existe una forma de diseño que garantiza la reproducibilidad y el rastreo preciso de lo que pasa, y es muy similar a como funciona la contabilidad (Contabilidad bien echa NUNCA hace ediciones o borrados, solo inserta pa' delante):
http://www.codeproject.com/Articles/...Event-sourcing
En resumen, debes guardar un log de cada pasa que se ejecuta, y hacer un replay para reconstuir el valor actual. Eso es lo que hace una BD con su log de transacciones.
En el modelo comun, tienes:
UPDATE Producto=1 Cant = 2 WHRE Id=1
Cuando esto termina, no sabes que paso antes. El proceso es *destructivo*
En cambio, si lo vuelves un log:
Inv ID=1 ADD Producto=1 Cant = 1
Inv ID=1 UPDATE Producto=1 Cant = 2
Inv ID=1 ADD Producto=2 Cant = 3
Inv ID=1 DELETE
Como vez, al hacer esto asi, tenes un log inmutable que puedes evaluar y saber exactamente que paso, en que orden, etc. Es la forma segura de darle la maxima integridad y fiabilidad (y tiene otros beneficios, pero dejemoslo asi por ahora).
Tambien, considero que es la forma correcta de implementar un inventario.
P.D: Para la velocidad de consultas, puedes tener una tabla auxiliar que mantiene el valor actual desde los triggers del log. Es *mas* trabajo, pero es la forma de tener una auditoria perfecta y fiable.