django AuditTrail vs Reversion

Question

Je travaille sur une nouvelle application Web. Je dois enregistrer toutes les modifications apportées à la base de données dans les tables d'audit. Le but de ces tables d’audit est que, plus tard, lors d’un véritable audit physique, nous puissions savoir ce qui s’est passé dans une situation, qui a édité ce qui était et quel était l’état de la base de données au moment de, par exemple. un calcul complexe. La plupart des tables d'audit seront donc écrites et non lues. Un rapport peut parfois être généré.

J'ai cherché la solution disponible

1. AuditTrail - simple et c'est pourquoi je me penche vers elle, je peux la comprendre code de fichier unique.
2. Reversion - semble assez simple à utiliser mais ne sait pas à quel point il serait facile de le modifier si nécessaire.
3. rcsField semble être très complexe et trop pour mes besoins

Je n’ai essayé aucune de ces expériences et j’ai donc voulu connaître certaines expériences réelles et celle que je devrais utiliser. par exemple. lequel est le plus rapide utilise moins d’espace, facile à étendre et à entretenir?

Answer 1

Comme je l'ai dit dans ma question, rcField semble être trop pour mes besoins, ce qui est simple: je veux stocker toutes les modifications apportées à ma table et pouvoir y revenir ultérieurement pour générer certains rapports.

J'ai donc testé AuditTrail et Reversion Reversion semble être une meilleure application complète avec de nombreuses fonctionnalités (dont je n’ai pas besoin). Aussi, autant que je sache, les données sont sauvegardées dans une seule table au format XML ou YAML, ce qui, je pense

1. générera trop de données dans une seule table
2. pour lire ces données, je ne pourrai peut-être pas utiliser les outils de base de données déjà présents.

AuditTrail gagne en ce sens que pour chaque table, il génère une table d'audit correspondante et que, par conséquent, les modifications peuvent être facilement suivies, les données par table sont réduites et peuvent être facilement manipulées et par l'utilisateur pour la génération de rapports.

Je vais donc avec AuditTrail.

Answer 2

Personnellement, je préfère créer des tables d’audit dans la base de données et les renseigner par le biais de déclencheurs afin que toutes les modifications, même les requêtes ad hoc, de la fenêtre de requête soient stockées. Je ne considérerais jamais une solution d'audit qui ne soit pas basée sur la base de données elle-même. Ceci est important car les personnes qui modifient mal la base de données ou commettent une fraude ne le feront probablement pas via l'interface Web, mais directement sur le backend. Beaucoup plus de ce genre de choses se produit chez des employés mécontents ou larviers que des pirates extérieurs. Si vous utilisez déjà un ORM, vos données sont exposées au risque car les autorisations se situent au niveau de la table plutôt qu'au niveau sp auquel elles appartiennent. Par conséquent, il est encore plus important que vous capturiez toute modification possible de la donnée, pas seulement celle de l'interface graphique. Nous avons un processus dynamique pour créer des tables d'audit qui est exécuté chaque fois que de nouvelles tables sont ajoutées à la base de données. Étant donné que nos tables d'audit ne renseignent que les modifications, et non l'ensemble de l'enregistrement, il n'est pas nécessaire de les modifier à chaque ajout d'un champ.

Lors de l’évaluation des solutions possibles, veillez également à prendre en compte la difficulté de rétablir les données pour annuler un changement spécifique. Une fois que vous avez les tables d’audit, vous constaterez que c’est l’une des tâches les plus importantes que vous devez faire à partir d’elles. Déterminez également à quel point il sera difficile de conserver les informations lorsque le schéma de la base de données sera modifié.

Choisir une solution, car elle semble être la solution la plus simple à comprendre, n’est généralement pas une bonne idée. Cela devrait être le plus bas de vos critères de sélection après avoir satisfait aux exigences, à la sécurité, etc.

Answer 3

Je ne peux vous donner une expérience réelle d'aucun d'eux, mais j'aimerais faire une observation.

Je suppose que par AuditTrail, vous voulez dire AuditTrail sur le wiki Django . Si tel est le cas, je pense que vous voudrez plutôt regarder HistoricalRecords développé par le même auteur (Marty Alchin, @gulopine) dans son livre Pro Django . Cela devrait fonctionner mieux avec Django 1.x.

C’est l’approche que je vais utiliser pour un projet à venir, non pas parce qu’il bat nécessairement les autres d’un point de vue technique, mais parce que cela correspond au "monde réel". attentes de la trace d'audit pour cette application.