La mise en œuvre Trail- Audit Spring AOP vs.Hibernate Interceptor vs DB Trigger

Question

J'ai trouvé deux fils de discussion sur this- mais rien qui a une comparaison de tous les mécanismes de trois sous un fil.

Alors, voici ma question ...

Je dois vérifier DB Modifications- insérer \ updates \ supprime les objets d'affaires.

Je peux penser à trois façons de le faire

1) DB triggers

2) Hibernate intercepteurs

3) Spring AOP

(Cette question est spécifique à un \ Spring Hibernate \ RDBMS- Je suppose que cela est neutre java \ c # ou mise en veille prolongée \ nhibernate- mais si votre réponse dépend de C ++ ou Java ou la mise en œuvre spécifique de hibernate- s'il vous plaît préciser)

Quels sont les avantages et les inconvénients de la sélection d'un de ces stratégies?

Je ne demande pas la mise en œuvre details.-Ce est une discussion de conception.

J'espère que nous pouvons faire cela comme une partie du wiki communautaire

Answer 1

Je ne peux parler Déclencheurs et NHibernate, parce que je ne sais pas tSpring AOP enought abou.

Cela dépend, comme toujours, ce qui est le plus important pour vous.

DB déclencheurs

• sont rapides
• sont toujours appelés, même à partir de SQL natif, des scripts, des applications externes.
• données d'écriture dans la base de données dont NH ne connaît pas. Il sera absent de la session en cours. (Ce qui pourrait conduire à des résultats inattendus)
• ne sait généralement rien au sujet de votre session. (Par exemple: nom de connexion)

NHibernate intercepteurs / événements

• ne sont pas spécifiques au SGBD.
• vous permet d'accéder facilement aux informations que vous d'affaires, comme la session utilisateur, le nom de la machine client, certains calculs ou interprétations, localisation, etc.
• vous permettre la configuration déclarative, comme les attributs de l'entité, qui définissent si l'entité doit être connecté et comment.
• vous permet de désactiver l'enregistrement, cela pourrait être important pour les mises à niveau, les importations, les actions spéciales qui ne sont pas déclenchées par l'utilisateur.
• vous permet une vue de l'entité au modèle d'affaires. Vous êtes probablement plus proche du point de vue des utilisateurs.

Answer 2

Je comprends que ce n'est pas 100% liée à la question mais il ajoute la valeur avec de nouvelles options.

Il y a deux façons dont vous pouvez auditer ce qui se passe.

Lecture journal des transactions: Si la base de données est en mode de récupération complète alors tous les détails sur INSERT, UPDATE, DELETE et DDL sont consignés dans journal des transactions.

Le problème est qu'il est très complexe à lire, car il est pas pris en charge en mode natif et que vous aurez besoin d'un lecteur de journal des transactions tiers tels que Log ApexSQL ou SQL Log de sauvetage (celui-ci est libre, mais ne supporte que SQL 2000).

L'avantage de cette méthode est que vous n'avez pas littéralement d'apporter des modifications à l'exception de mettre votre base de données en mode de récupération complète.

traces SQL Server: Traces capteront tout dans les fichiers de trace, y compris les instructions select qui peuvent être nécessaires aussi pour certains scénarios de conformité. L'inconvénient est que les traces sont des fichiers texte qui doivent être analysés et organisés.

Answer 3

Je ne peux pas penser à une bonne raison de ne pas la base de données en utilisant des déclencheurs pour auditer des modifications à la base de données. Les insertions, mises à jour et les suppressions peuvent potentiellement frapper la base de données à partir de diverses sources - déclencheurs attraperont tous ces; Mise en veille prolongée, etc. ne sera pas.

Answer 4

Je tink lorsque l'on considère l'audit, vous devez considérer ce qu'il est pour. Tout d'abord, il est à havea record qui changé quoi et ce qui a changé pour que vous puissiez sauvegarder les mauvaises modifications, vous pouvez identifier les problèmes avec le système (nous pouvons voir que de plusieurs applications differnt casued le changement qui permet d'identifier rapidement que l'on est cassé) et donc vous pouvez identifier qui a fait le changement. Le dernier peut être vraiment critique en matière de détection de la fraude. Si vous faites tout de l'interface utilisateur, vous ne verrez jamais l'utilisateur commettre une fraude qui change les données dans le back-end pour se faire un chèque. Si vous faites tout de l'interface, probablement vous devez disposer des autorisations définies au niveau de Tabel, ouvrant ainsi la porte à la fraude pour commencer. Si vous faites tout de l'interface que vous ne saurez pas quel employé mécontent a supprimé la totalité de la table d'utilisateur pour la valeur pure contrariété. Si vous faites tout de l'avant, vous ne saurez pas qui dba incompétent accidentellement mis à jour toutes les commandes des clients au même client. Je ne peux pas supporter tout sauf en utilisant des déclencheurs pour la vérification que vous perdez une bonne partie de la raison pour laquelle vous avez besoin d'audit en premier lieu.

Answer 5

Utilisation Hibernate intercepteurs pour effectuer des journaux d'audit est profondément erronée. Je suis abasourdi par le nombre de blogs qui recommandent cette méthode sans rappeler son défaut le plus évident - l'intercepteur doit utiliser une nouvelle transaction pour enregistrer l'audit. Ce qui signifie que vous pourriez économiser avec succès la transaction principale et un plantage du système qui ne parvient pas à enregistrer la transaction d'audit!

Answer 6

une vieille question que je tombai sur now.There est une option de plus disponible et est disponible Envers avec mise en veille prolongée à partir de ver 3.6 partir ..