¿Cómo manejar mejor el almacenamiento de datos históricos?

Question

Estoy tratando de determinar cómo debo almacenar datos transaccionales históricos.

¿Debo almacenarlo en una sola tabla donde el registro simplemente se reinserta con una nueva marca de tiempo cada vez?

¿Debería dividir los datos históricos en una tabla separada de 'historial' y solo mantener los datos actuales en la tabla 'activa'?

Si es así, ¿cómo hago mejor eso? ¿Con un disparador que copia automáticamente los datos a la tabla de historial? ¿O con lógica en mi aplicación?

Actualización por comentario de Welbog:

Habrá grandes cantidades de datos históricos (cientos de miles de filas, eventualmente millones)

Principalmente las operaciones de búsqueda e informes se ejecutarán en los datos históricos.

El rendimiento es una preocupación. Las búsquedas no deberían tener que ejecutarse toda la noche para producir resultados.

Answer 1

Si el requisito es únicamente para informes, considere construir un almacén de datos separado. Esto le permite utilizar estructuras de datos como dimensiones que cambian lentamente y que son mucho mejores para informes históricos pero que no funcionan bien en un sistema transaccional. La combinación resultante también elimina los informes históricos de su base de datos de producción, lo que será una ganancia de rendimiento y mantenimiento.

Si necesita que este historial esté disponible dentro de la aplicación, entonces debe implementar algún tipo de versión o función de eliminación lógica o hacer que todo se contrarreste y repita (es decir, las transacciones nunca se eliminan, solo se revierten y se reinician). Piense con mucho cuidado si realmente necesita esto, ya que agregará mucha complejidad. Hacer una aplicación transaccional que pueda reconstruir el estado histórico correctamente es considerablemente más difícil de lo que parece. El software financiero (por ejemplo, los sistemas de suscripción de seguros) no logra hacer esto mucho más de lo que podría pensar.

Si necesita el historial únicamente para el registro de auditoría, haga tablas de sombra y disparadores de registro de auditoría. Esto es mucho más simple y robusto que intentar implementar de manera correcta e integral el registro de auditoría dentro de la aplicación. Los desencadenantes también recogerán cambios en la base de datos de fuentes externas a la aplicación.

Answer 2

Esta pregunta sigue la línea de Business Logic. Conozca los requisitos de su negocio primero y luego comience desde allí. Un Data Warehouse es una buena solución para este tipo de situación. ETL le dará muchas opciones para lidiar con los flujos de datos. Su concepto básico de 'Historia' vs 'Activo' es bastante correcto. Sus datos históricos serán más eficientes y flexibles si se guardan en un almacén de datos con todas sus tablas de dimensiones y hechos.