Implementieren von Audit Trail - Spring AOP vs Hibernate Interceptor vs DB-Trigger

Question

Ich habe einige Diskussionsfäden zu diesem Thema gefunden - aber nichts, was einen Vergleich aller drei Mechanismen unter einem Thread brachte.

So, hier ist meine Frage ...

Ich brauche DB Änderungen- Einsatz \ Updates \ löscht, um Business-Objekte zu prüfen.

kann ich drei Möglichkeiten denken, dass dieses

1) DB-Trigger

2) Hibernate Abfangjäger zu tun

3) Frühling AOP

(Diese Frage an einen Frühling \ spezifisch ist Hibernate \ RDBMS- Ich denke, das ist neutral zu Java \ C# oder Ruhezustand \ nhibernate- aber wenn Ihre Antwort hängt von C++ oder Java oder spezifische Implementierung von Ruhezustand - bitte angeben)

Was sind die Vor- und Nachteile der Auswahl einer dieser Strategien?

Ich frage nicht nach Implementierungsdetails.-Dies ist eine Design-Diskussion.

Ich hoffe, wir dies als Teil der Community Wiki machen

Answer 1

Ich kann nur über Trigger und NHibernate sprechen, weil ich nicht genug über Spring AOP weiß.

Es hängt wie immer davon ab, was für Sie am wichtigsten ist.

DB löst

• schnell
• sind immer aufgerufen, auch aus nativen SQL-Skripte, externe Anwendungen.
• Daten in den DB schreiben, von denen NH nichts weiß. Es wird in der aktuellen Sitzung fehlen. (Was zu unerwarteten Ergebnissen führen könnte)
• wissen normalerweise nichts über Ihre Sitzung (sagen wir: Login-Name).

NHibernate Abfangjäger/Ereignisse

• sind nicht spezifisch DBMS.
• ermöglichen Ihnen den einfachen Zugriff auf Ihre Geschäftsinformationen, wie die Benutzersitzung, Client-Computername, bestimmte Berechnungen oder Interpretationen, Lokalisierung usw.
• können Sie deklarative Konfiguration, wie Attribute auf der Entität, die definieren, wenn die Entität benötigt protokolliert werden und wie.
• können Sie die Protokollierung deaktivieren, dies könnte für Upgrades, Importe, spezielle Aktionen, die nicht vom Benutzer ausgelöst werden, wichtig sein.
• ermöglichen Ihnen eine Entitätsansicht für das Geschäftsmodell. Sie sind wahrscheinlich näher am Standpunkt des Benutzers.

Answer 2

ich nicht von jedem guten Grund denken kann für nicht-Datenbank löst Änderungen in der Datenbank zu überprüfen. Einfügungen, Aktualisierungen und Löschungen können möglicherweise die Datenbank von verschiedenen Quellen treffen - Auslöser fangen alle diese ab; Hibernate usw. nicht.

Answer 3

Ich denke, wenn Sie Auditing in Betracht ziehen, müssen Sie überlegen, was es ist. Erstens, es ist eine Aufzeichnung darüber, wer was geändert hat und was sich geändert hat, so dass Sie schlechte Änderungen rückgängig machen können. Sie können Probleme mit dem System identifizieren (wir können sehen, welche von verschiedenen Anwendungen die Änderung ausgelöst hat, die schnell identifiziert, welche defekt ist). und so können Sie identifizieren, wer die Änderung vorgenommen hat. Die letzte kann wirklich entscheidend sein, wenn es um die Aufdeckung von Betrug geht. Wenn Sie alles von der Benutzeroberfläche aus tun, werden Sie nie einen betrügerischen Benutzer sehen, der die Daten im Backend ändert, um selbst einen Scheck zu schreiben. Wenn Sie alles über die Benutzeroberfläche ausführen, müssen Sie wahrscheinlich Berechtigungen auf Tabellenebene festlegen und damit die Tür für Betrug öffnen. Wenn Sie alles von der Oberfläche aus tun, werden Sie nicht wissen, welcher verärgerte Mitarbeiter die gesamte Benutzertabelle für den reinen Störungswert gelöscht hat. Wenn Sie alles vom Frontend aus tun, werden Sie nicht wissen, welche inkompetente dba versehentlich alle Kundenaufträge an denselben Kunden aktualisiert hat. Ich kann nichts anderes als Trigger für das Auditing unterstützen, da Sie einen guten Teil davon verlieren, warum Sie überhaupt Auditing benötigen.

Answer 4

Die Verwendung von Hibernate-Interceptors zur Durchführung von Audit-Protokollen ist zutiefst fehlerhaft. Ich bin verblüfft über die Anzahl der Blogs, die diese Methode empfehlen, ohne auf den offensichtlichen Fehler hinzuweisen - der Abfangjäger muss eine neue Transaktion verwenden, um das Audit aufzuzeichnen. Das bedeutet, dass Sie die Haupttransaktion erfolgreich speichern und einen Systemabsturz durchführen können, der die Überwachungstransaktion nicht aufzeichnet!

Answer 5

eine alte Frage, die ich auf now.There chanced ist eine weitere Option zur Verfügung, und das ist Envers, die von ver 3.6 beginnend ab zusammen mit Hibernate zur Verfügung steht ..

Answer 6

Ich verstehe das nicht 100% ist auf den im Zusammenhang Frage, aber es fügt Wert mit neuen Optionen hinzu.

Es gibt zwei weitere Möglichkeiten, um zu prüfen, was passiert.

Transaktionsprotokoll lesen: Wenn sich die Datenbank im vollständigen Wiederherstellungsmodus befindet, werden alle Details zu INSERT-, UPDATE-, DELETE- und DDL-Anweisungen im Transaktionslog protokolliert.

Problem ist, dass es sehr komplex ist zu lesen, weil es nicht nativ unterstützt wird und dass Sie einen Dritten Transaktionsprotokollleser wie ApexSQL Log oder SQL Log Rescue müssen (letzteres ist kostenlos, aber unterstützt nur SQL 2000).

Vorteil dieser Methode ist, dass Sie buchstäblich keine Änderungen vornehmen müssen, außer Ihre Datenbank in den vollständigen Wiederherstellungsmodus zu versetzen.

SQL Server-Traces: Traces erfassen alles in Trace-Dateien, einschließlich Select-Anweisungen, die möglicherweise auch für einige Compliance-Szenarien benötigt werden. Der Nachteil ist, dass Traces Textdateien sind, die geparst und organisiert werden müssen.