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

Question

J'essaie de déterminer comment je devrais stocker des données transactionnelles historiques. Dois-je le stocker dans une seule table où l'enregistrement est simplement réinséré avec un nouvel horodatage à chaque fois? Dois-je diviser les données d'historique dans un tableau d'historique séparé et ne garder que les données actuelles dans le tableau «actif».

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

mise à jour par le commentaire de Welbog:

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

Principalement des recherches et des opérations de déclaration seront exécutées sur les données historiques .

Les performances sont une préoccupation. Les recherches ne devraient pas avoir à fonctionner toute la nuit pour produire des résultats.

Answer 1

Si le besoin concerne uniquement la génération 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 qui changent lentement et qui sont bien meilleures pour les rapports historiques, mais qui ne fonctionnent pas bien dans un système transactionnel. La combinaison résultante déplace également le rapport historique de votre base de données de production, ce qui constitue un gain de performance et de maintenance. Si vous avez besoin que cet historique soit disponible dans l'application, vous devez implémenter une sorte de fonctionnalité de version ou de suppression logique ou tout faire entièrement contraster et redéfinir (par exemple, les transactions ne sont jamais effacées, simplement annulées et reformulées). Pensez très soigneusement si vous vraiment besoin de cela car il va ajouter beaucoup de complexité. Faire une application transactionnelle capable de reconstruire l'état historique correctement est considérablement plus difficile qu'il n'y paraît. Les logiciels financiers (par exemple les systèmes de souscription d'assurance) 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 masquées et des déclencheurs de journalisation d'audit. Ceci est beaucoup plus simple et plus robuste que d'essayer de mettre en œuvre correctement et complètement la journalisation d'audit au sein de l'application. Les déclencheurs détecteront également les modifications apportées à la base de données à partir de sources extérieures à l'application.

Answer 2

Cette question s'inscrit dans la lignée de Business Logic. Connaissez d'abord les exigences de votre entreprise, puis commencez à partir de là. Un Data Warehouse est une bonne solution pour ce genre de situation. ETL vous donnera beaucoup d'options pour gérer les flux de données. Votre concept de base 'Histoire' vs 'Actif' est tout à fait correct. Vos données d'historique seront plus efficaces et plus flexibles si elles sont conservées dans un entrepôt de données avec toutes leurs tables de dimension et de faits.