Stratégie efficace pour laisser une piste d'audit/un historique des modifications pour les applications de base de données ?

Question

Quelles sont les stratégies avec lesquelles les gens ont réussi à conserver un historique des modifications des données dans une base de données assez complexe ?L'une des applications que j'utilise et pour laquelle je développe fréquemment pourrait vraiment bénéficier d'une méthode plus complète de suivi de l'évolution des enregistrements au fil du temps.Par exemple, à l'heure actuelle, les enregistrements peuvent avoir un certain nombre d'horodatages et de champs utilisateur modifiés, mais nous n'avons actuellement pas de système pour enregistrer plusieurs modifications, par exemple si une opération est annulée.Dans un monde parfait, il serait possible de reconstituer l'enregistrement tel qu'il était après chaque sauvegarde, etc.

Quelques infos sur la DB :

• Doit avoir la capacité de croître de milliers d'enregistrements par semaine
• 50-60 tableaux
• Les principales tables révisées peuvent contenir plusieurs millions d'enregistrements chacune
• Quantité raisonnable de clés étrangères et d'index définis
• Utilisation de PostgreSQL 8.x

Answer 1

Dans le passé, j'ai utilisé des déclencheurs pour créer une journalisation de mise à jour/insertion/suppression de base de données.

Vous pouvez insérer un enregistrement chaque fois qu'une des actions ci-dessus est effectuée sur une table spécifique dans une table de journalisation qui garde une trace de l'action, de l'utilisateur de la base de données qui l'a effectuée, de l'horodatage, de la table sur laquelle elle a été effectuée et de la valeur précédente.

Il existe probablement une meilleure réponse, car cela vous obligerait à mettre en cache la valeur avant que la suppression ou la mise à jour ne soit effectuée, je pense.Mais vous pouvez l'utiliser pour effectuer des restaurations.

Answer 2

Une stratégie que vous pouvez utiliser est MVCC, Multi-Value Concurrency Control.Dans ce schéma, vous n'effectuez jamais de mises à jour d'aucune de vos tables, vous effectuez simplement des insertions, en conservant les numéros de version pour chaque enregistrement.Cela présente l’avantage de fournir un instantané exact à tout moment et d’éviter complètement les problèmes de verrouillage de mise à jour qui affectent de nombreuses bases de données.

Mais cela crée une énorme base de données et les sélections nécessitent toutes une clause supplémentaire pour sélectionner la version actuelle d'un enregistrement.

Answer 3

Si vous utilisez Hibernate, jetez un œil à JBoss Envers.Depuis la page d'accueil du projet :

Le projet Envers vise à permettre une gestion facile des versions 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 souhaitez versionner, avec @Versioned.Pour chaque entité versionnée, une table sera créée, qui contiendra l'historique des modifications apportées à l'entité.Vous pouvez ensuite récupérer et interroger les données historiques sans trop d'effort.

Cela ressemble un peu à L'approche d'Éric, mais probablement beaucoup moins d'effort.Cependant, je ne sais pas quelle langue/technologie vous utilisez pour accéder à la base de données.

Answer 4

Le seul problème avec l'utilisation des déclencheurs est qu'ils augmentent les performances de toute insertion/mise à jour/suppression.Pour une évolutivité et des performances supérieures, vous souhaitez limiter les transactions de base de données au minimum.L'audit via des déclencheurs augmente le temps nécessaire pour effectuer la transaction et, en fonction du volume, peut entraîner des problèmes de performances.

une autre façon consiste à explorer si la base de données fournit un moyen d'extraire les journaux « Redo » comme c'est le cas dans Oracle.Les journaux de rétablissement sont ce que la base de données utilise pour recréer les données en cas d'échec et de récupération.

Answer 5

Semblable à un déclencheur (ou même avec), vous pouvez faire en sorte que chaque transaction déclenche un événement de journalisation de manière asynchrone et qu'un autre processus (ou simplement un thread) gère réellement la journalisation.Il existe de nombreuses façons de mettre en œuvre cela en fonction de votre application.Je suggère que l'application déclenche l'événement afin qu'il ne provoque pas de charge inutile sur votre première transaction (ce qui conduit parfois à des verrous à partir des journaux d'audit en cascade).

En outre, vous pourrez peut-être améliorer les performances de la base de données principale en conservant la base de données d'audit dans un emplacement distinct.

Answer 6

J'utilise SQL Server, pas PostgreSQL, donc je ne sais pas si cela fonctionnera pour vous ou non, mais Pop Rivett a publié un excellent article sur la création d'une piste d'audit ici :FAQ n°5 sur SQL Server de Pop Rivett :Accédez à la piste d'audit

Créez une table d'audit, puis créez un déclencheur pour chaque table que vous souhaitez auditer.

Indice:utiliser Forgeron de codes pour construire vos déclencheurs.