Que tan confiable es MySQL

[darkerbyte]

Mamcx

El cliente me reporta que hacen una venta y los productos que ha vendido los cuales deberían haber sido descontados siguen apareciendo en existencia.
Por eso comenté que tenía mi duda al respecto con esta instrucción:

UPDATE productos SET almacen=almacen-3.00 WHERE clave='PDE'; --En este caso se vendieron 3 pzas del producto 'PDE'

Para cada producto que se vende se inserta la partida en la tabla de "ventas_det" y se hace el desconteo respectivo en la tabla de productos. Después de revisar el kardex veo que efectivamente tengo existencia de más del producto.
Esto es muy extraño porque el algoritmo genera las dos consultas, tanto para insertar como para descontar y lo hace dentro de una transacción y he probado cientos de veces, sin exagerar quizá miles de veces el procedimiento, tranzando paso a paso.
Igual al cliente no se lo hace en todas las ventas, ni en todos los productos.
He cuidado que las claves de los productos de los clientes no tengan símbolos especiales (comillas, asteriscos, etc). Para que no pudieran dar alguna falla en la consulta por el propio lenguaje de MySQL

Creo que es cosa del Chamuco, como decimos por acá.

[Casimiro Notevi]

Empezado por darkerbyte

UPDATE productos SET almacen=almacen-3.00 WHERE clave='PDE'; --En este caso se vendieron 3 pzas del producto 'PDE'

Eso no son 3 piezas, sino 3.00

[mamcx]

Conceptualmente es el problema que resuelve la contabilidad doble: Si no se conserva la historia y flujo de las transacciones se pueden generar errores (o fraudes).

El problema de fondo es que el manejo del estado de los datos normales en forma CRUD es *destructivo* y no hay manera de saber como se llego al resultado actual. Para un inventario, al igual que un libro contable - de hecho, un inventario es una forma especial de contabilidad- es mas solido usar un diseño inmutable (donde no se sobreescribe sino que se agregan los resultados).

Osea, un log.

Es mejor que el inventario sea asi:

Feb1 - Ref:ABC BUY = Qty:1, Value:$10
Feb2 - Ref:ABC SELL = Qty:1, Value:$15
Feb3 - Ref:ABC BUY = Qty:10, Value:$20
Feb3 - Ref:ABC TRANSFER = Qty:10, Value:$20 TO Store: 2

Nota: Se registra luego de hacer las validaciones. Por eso, si no se permiten vender por debajo del stock, no saldran lineas con inventarios negativos. Osea, se registra solo un hecho real y concreto (en el pasado) y no lo que se va a hacer y que *puede* ser rechazado por la logica del negocio.


Y usar la tabla de inventarios como "cache" con el valor actual del stock (Asi que obvio tienes un campo Stock actual). Asi, teniendo la historia en forma de log, puedes tener claro como se movio el flujo del inventario.

Entonces, si hay un problema con un producto, puedes consultar tu log y ver en que momento se genero el problema.

[darkerbyte]

Ya hice la complementación para generar un archivo log. Para cada procedimiento el programa guarda lo que el usuario tiene en pantalla y las consultas que el sistema envía al servidor. Ahora a dar un poco de tiempo para empezar a rastrear los archivos

[darkerbyte]

Usando la idea de Mamcx agregué a cada procedimiento que "mete mano" a la base de datos un log de la información que tengo en pantalla junto con la consulta que está enviando a MySQL para serciorarme que no fuese un error de programación mío.

También implementé en el sistema un método para capturar el estado del inventario (screenshot) que almacena para cada producto
la existencia en cada sucursal junto con el costo del producto. Por supuesto se guarda también la fecha y hora de captura.

Mis clientes volvieron a tener problemas con las existencias de su inventario.
El día 4 estuve haciendo unas pruebas, hice una captura de inventario, el día 5 se registró un movimiento para dos productos
fue una única venta, en el archivo log esto es lo que tenía en pantalla:



Cantidad Clave Descripción Precio Unitario, importe

0.50 ; 520100106; ULTRAFONDO TRANSP. CATALIZABLE GRANEL; Menudeo; 85.50; 42.75 ;
0.50 ; 521101806; CATALIZADOR AL 100% P/ULTRAFONDO GRANEL; Menudeo; 84.50; 42.25 ;

Y aquí lo que se mandó al servidor

Código SQL [-]
START TRANSACTION;
INSERT INTO ventas VALUES (1,8126, '2016-10-05', '17:42:48', 1, 3,282,'',0, 0, 0, 0);
INSERT INTO pedidos VALUES(1,8126,'520100106',0,0.50,1,65.96,85.50);
INSERT INTO pedidos VALUES(1,8126,'521101806',1,0.50,1,65.01,84.50);
UPDATE productos set suc1=suc1-0.50 WHERE clave='520100106';
UPDATE productos set suc1=suc1-0.50 WHERE clave='521101806';
Commit;

El punto es este, pueden ver que en las dos ultimas lineas se resta de la existencia en la sucursal 1 [suc1(decimal(8,2)] la cantidad vendida 0.5
En el screenshot que hice de mi inventario tenía 9.70 piezas y después de esta venta tengo una existencia de 6.20 en el producto "520100106, ULTRAFONDO TRANSP. CATALIZABLE GRANEL"

Escribo el resultado de mis pruebas por si alguien más a futuro pasa por una situación similar. Versión de MySQL la 5.1.33


Voy a probar con otra versión de MySQL porque ya me volví loco haciendo debugs y probando cientos de veces el codigo fuente
o quizá me cambie a Firebird

[[AgustinOrtu]]

Llego tarde al tema, pero la idea que propone Mario (mamcx) es sin duda la manera mas adecuada. Lo que el propone se conoce (o al menos, Martin Fowler le pone este nombre) como Event Sourcing. En ese link, el propio Fowler da una introduccion al tema y explica como implementarlo.

El articulo esta en ingles, y como se trata de Fowler, se habla pura y exclusivamente de objetos (POO), pero el concepto es el mismo asi se implemente a nivel BD (usando triggers o disparadores, por ejemplo)

La idea general de Event Sourcing es que todo lo que sea transformaciones de estado (agregar, actualizar o borrar) sea capturado por objetos que el define como "Event Objects". Estos objetos lo que hacen es ir "apilando" los cambios uno atras de otro, llevando un changelog, es decir, en lugar de tener el "ultimo estado" per se, se tiene un registro. Luego para obtener el estado actual, la aplicacion deberia levantar el log, e ir aplicando en orden todos los cambios hasta el ultimo. Tambien explica que esto podria ser lento si son muchos registros para procesar, y como hacer para solucionarlo

Este diseño lleva a varias ventajas:
- Poder reconstruir el estado de la aplicacion: Simplemente levantas todo el log y aplicas todos los cambios a una aplicacion "vacia"
- Consultas a lo largo del tiempo: Es posible preguntar cual era el estado en cualquier fecha, ya que tu aplicacion es capaz de reconstruirse desde el inicio hasta cualquier fecha determinada
- Se pueden revertir cambios: Si una serie de eventos tuvo algun resultado incorrecto, se puede volver al estado inicial "deshaciendo" los eventos en orden inverso, volviendo al estado correcto y a su vez llevando el registro de lo incorrecto

Ejemplos de este tipo de sistema son los que se encargan de versionar el codigo fuente. Git, subversion, mercurial, permiten ver una "foto" de como era tu codigo exactamente hace un año, por ejemplo.

[[Al González]]

Hola darkerbyte. Sé que dijiste que los resultados no parecen obedecer a un patrón lógico. Pero intentemos determinar la función matemática que representa a esas discrepancias.

9.7 - 0.5 da 6.2 (como si se restara 0.5 siete veces).
...(Coloca más líneas así con valores de la misma operación, incluyendo los que sean correctos. Sospecho de las decimales.)