Comment gérer au mieux le stockage des données historiques?

Question

J'essaie de déterminer comment stocker les données transactionnelles historiques.

Devrais-je le stocker dans une seule table où l'enregistrement est simplement réinséré avec un nouvel horodatage à chaque fois?

Dois-je décomposer les données historiques dans une table séparée "historique" et ne conserver que les données actuelles dans la table "active"?

Si oui, comment puis-je le faire au mieux? Avec un déclencheur qui copie automatiquement les données dans la table d'historique? Ou avec de la logique dans mon application?

Mise à jour selon le commentaire de Welbog:

Il y aura de grandes quantités de données historiques (des centaines de milliers de lignes - éventuellement des millions de lignes)

Les recherches et les opérations de génération de rapports sont principalement exécutées sur les données historiques.

La performance est une préoccupation. Les recherches ne doivent pas nécessairement durer toute la nuit pour produire des résultats.

Answer 1

Si l'exigence concerne uniquement la création de rapports, envisagez de créer un entrepôt de données distinct. Cela vous permet d'utiliser des structures de données telles que des dimensions à évolution lente, bien meilleures pour la génération de rapports historiques mais qui ne fonctionnent pas bien dans un système transactionnel. La combinaison résultante éloigne également l'historique des rapports de votre base de données de production, ce qui sera un avantage en termes de performances et de maintenance.

Si vous avez besoin que cet historique soit disponible dans l'application, vous devez implémenter une sorte de fonctionnalité de suppression de version ou de contrôle logique ou tout mettre complètement en contradiction et reformuler (c'est-à-dire que les transactions ne sont jamais supprimées, mais simplement inversées et reformulées). Réfléchissez très attentivement pour savoir si vous vraiment avez besoin de cela car cela va ajouter beaucoup de complexité. Créer une application transactionnelle capable de reconstruire correctement un état historique est considérablement plus difficile qu'il n'y paraît. Les logiciels financiers (systèmes de souscription d’assurances, par exemple) ne le font pas beaucoup plus que vous ne le pensez.

Si vous avez besoin de l'historique uniquement pour la journalisation d'audit, créez des tables fantômes et des déclencheurs de journalisation d'audit. Cela est beaucoup plus simple et plus robuste que d'essayer de mettre en œuvre correctement et de manière exhaustive la journalisation d'audit dans l'application. Les déclencheurs enregistreront également les modifications apportées à la base de données à partir de sources extérieures à l'application.

Answer 2

Cette question se situe dans la lignée de la logique applicative. Connaissez d’abord les besoins de votre entreprise, puis commencez par là. Un entrepôt de données est une solution intéressante pour ce genre de situation. ETL vous donnera beaucoup d'options pour gérer les flux de données. Votre concept de base de "Histoire" vs "Actif" est tout à fait correct. Vos données d'historique seront plus efficaces et flexibles si elles sont conservées dans un entrepôt de données avec toutes leurs tables de dimensions et de faits.