Stratégie efficace pour laisser une piste de vérification/historique de changement pour les applications PD?
quelles sont les stratégies qui ont réussi à maintenir un historique de changement pour les données dans une base de données assez complexe? Une des applications que j'utilise et développe fréquemment pour pourrait vraiment bénéficier d'une façon plus complète de suivre comment les dossiers ont changé au fil du temps. Par exemple, pour le moment, les enregistrements peuvent avoir un certain nombre de timestamp et de champs utilisateur modifiés, mais nous n'avons pas de schéma pour la journalisation des changements multiples, par exemple si une opération est restaurée. Dans un monde idéal, il serait possible de reconstruire l'enregistrement après chaque sauvegarde, etc.
quelques infos sur le DB:
- doit avoir la capacité de croître par des milliers de dossiers par semaine
- 50-60 Tables
- Principal revisioned tables peuvent avoir plusieurs millions de documents chaque
- nombre raisonnable de clés et d'indices étrangers
- Utilisation De PostgreSQL 8.x
6 réponses
dans le passé, j'ai utilisé des triggers pour construire la journalisation db update/insert/delete.
vous pouvez insérer un enregistrement chaque fois qu'une des actions ci-dessus est faite sur une table spécifique dans une table de journalisation qui garde la trace de l'action, ce que l'utilisateur de db l'a fait, timestamp, table il a été préformé sur, et la valeur précédente.
Il ya probablement une meilleure réponse, bien que cela vous exigerait de mettre en cache la valeur avant la suppression réelle ou la mise à jour a été préformé, je pense. Mais tu pourrais utiliser ça pour faire des retours en arrière.
une stratégie que vous pourriez utiliser est MVCC, Multi-valeur contrôle de la concurrence. Dans ce schéma, vous ne faites jamais de mises à jour à aucune de vos tables, vous faites juste des inserts, en maintenant des numéros de version pour chaque enregistrement. Cela a l'avantage de fournir un instantané exact de n'importe quel point dans le temps, et il évite complètement les problèmes de serrure de mise à jour qui affligent de nombreuses bases de données.
mais il fait pour une base de données énorme, et sélectionne tous nécessitent une clause supplémentaire pour sélectionner le courant version d'un enregistrement.
si vous utilisez Hibernate, jetez un oeil à JBoss Envers . De la page d'accueil du projet:
le projet Envers vise à permettre la vérification facile des classes JPA persistantes. Tout ce que vous avez à faire est d'annoter votre classe persistante ou certaines de ses propriétés, que vous voulez version, avec @Versioned. Pour chaque versionnées entité, une table sera créée, qui va contenir l'historique des modifications apportées à l'entité. Vous pouvez ensuite extraire et interroger des données historiques sans grand effort.
c'est quelque peu similaire à l'approche D'Eric , mais probablement beaucoup moins d'effort. Je ne sais pas, quelle langue/technologie vous utilisez pour accéder à la base de données, cependant.
le seul problème avec L'utilisation de Triggers est qu'il ajoute aux frais généraux de performance de n'importe quel insert/update/delete. Pour une plus grande évolutivité et des performances plus élevées, vous souhaitez garder la transaction de la base de données au minimum. La vérification au moyen de déclencheurs augmente le temps requis pour effectuer la transaction et, selon le volume, peut causer des problèmes de rendement.
une autre façon consiste à explorer si la base de données fournit un moyen quelconque d'extraire les journaux" Redo " comme C'est le cas dans Oracle. Refaire les journaux est ce que la base de données utilise pour recréer les données dans le cas où il échoue et doit récupérer.
similaire à un déclencheur (ou même avec) vous pouvez avoir chaque transaction qui déclenche un événement de journalisation de façon asynchrone et avoir un autre processus (ou tout simplement un thread) qui gère réellement la journalisation. Il y aurait plusieurs façons de mettre en œuvre ceci selon votre application. Je suggère que l'application déclenche l'événement de sorte qu'il ne cause pas de charge inutile sur votre première transaction (qui conduit parfois à des serrures à partir des journaux d'audit en cascade).
En outre, vous pouvez être en mesure améliorer le rendement de la base de données principale en gardant la base de données de vérification à un endroit distinct.
j'utilise SQL Server, pas PostgreSQL, donc je ne suis pas sûr que cela fonctionne pour vous ou pas, mais Pop Rivett avait un grand article sur la création d'une piste d'audit ici: Pop rivett's SQL Server FAQ no. 5: Pop on the Audit Trail
Construire une table d'audit, puis créez un déclencheur pour chaque table que vous souhaitez auditer.
Conseil: utilisez Codesmith pour construire vos déclencheurs.