Cómo lograr un historial de inventario con auditoría sin perder rendimiento?

[BrandonPS]

Estoy diseñando un sistema de inventario y me encuentro con el clásico problema de que necesito guardar el historial de cambios de cada producto, pero no estoy seguro de cuál es la mejor forma de estructurar las tablas. He pensado en usar un patrón de auditoría, pero me preocupa que ralentice demasiado las consultas principales. Alguien que haya implementado un sistema de auditoría similar, ¿cómo manejaron el equilibrio entre tener el historial completo y mantener el rendimiento?

[Tyler54]

Yo implemente algo similar para un catalogo amplio. Mantuvimos la tabla actual de productos y añadimos una tabla de auditoría con columnas mínimas id_producto version timestamp tipo_cambio y valor_nuevo. Usamos particiones mensuales y vistas materializadas para las consultas de historial. Las consultas diarias de inventario no tocan la auditoría solo se unen a la versión mas reciente. El truco fue hacer el log de forma asincrona y limpiar versiones antiguas después de un periodo sin perder la capacidad de reconstruir el estado a una fecha dada. En resumen la auditoría existe pero no obstaculiza las lecturas cuando se consulta el stock actual

[Gary32]

Puede ser que te enfoques demasiado en el historial y termines haciendo un monstruo de consultas. Yo dejaría la auditoría para cambios relevantes como stock precio y ubicación y no para cada campo de cada registro. Guardaría difs o índices invertidos para las columnas que cambian a menudo. Así el rendimiento de las consultas principales se mantiene y el historial se guarda lo suficiente para auditoría legal. ¿No sería más eficiente modelar el historial a nivel de negocio que al nivel de fila por fila

[Mia52]

Mi primera idea fue auditoría total pero luego vi que a veces basta con registrar solo movimientos de stock y cambios de precio. Si el resto se puede reconstruir a partir de eventos eso aligera las tablas. Puede parecer que el registro detalle es imprescindible pero la realidad es que el negocio decide que datos importan. igual el equipo termina leyendo el historial a traves de vistas si se diseña bien

[AndrewJ]

Si tu pila lo permite usa tablas temporales de sistema o version temporal para reconstruir estados sin penalizar las lecturas actuales. En algunas bases hay soluciones de historia de filas. Mantienes la tabla actual y una tabla de historial con un rango de tiempo y indices sobre id_producto y periodo para las busquedas. Esto da flexibilidad y mantiene rendimiento sin perder la capacidad de ver el pasado

[MasonJ]

Pienso en un enfoque orientado a eventos. En lugar de guardar cada fila de historial guarda eventos como stock_in stock_out cambio_unitario y price_change y reconstruyes el estado a partir de la secuencia. Así el historial existe pero se accede de forma diferida. Esto funciona bien cuando necesitas auditoría y a la vez rendimiento, siempre que definas bien el orden de los eventos y las claves de version

[ScottJ]

Me pasa cuando diseño interfaces de usuario para inventario que las personas esperan ver el historial pero no quieren leer un archivo enorme. a veces el valor esta en la expectativa del lector mas que en el dato en si. Auditoría aparece como una capa adicional que algunos ven molesta, otros la exigen por confianza. al final depende de la tolerancia personal hacia personajes de equipos y de como repartes las cargas entre escritura y lectura