Implementazione Audit Trail- Spring AOP vs. Hibernate Interceptor vs DB Trigger

Question

Ho trovato un paio di thread di discussione su questo - ma nulla che ha portato un confronto di tutti e tre i meccanismi sotto un thread.

Così qui è la mia domanda ...

Ho bisogno di verificare DB Revisioni- inserto \ aggiornamenti \ eliminazioni di oggetti di business.

mi viene in mente tre modi per fare questo

1) DB trigger

2) Hibernate intercettori

3) Molla AOP

(Questa domanda è specifico di una primavera \ Hibernate \ RDBMS- Immagino che questo sia neutro rispetto a java \ C# o ibernato \ nhibernate- ma se la tua risposta dipende da C++ o Java o dall'implementazione specifica di hibernate, specifica per favore)

Quali sono i pro e i contro della selezione di una di queste strategie?

Non sto chiedendo dettagli di implementazione. - Questa è una discussione sul design.

spero possiamo fare questo come una parte della comunità wiki

Answer 1

Posso parlare solo di Trigger e NHibernate, perché non so abbastanza a proposito di AOP.

Dipende, come sempre, da ciò che è più importante per te.

DB innesca

• sono veloci
• sono sempre chiamati, anche da SQL nativo, script, applicazioni esterne.
• scrive i dati nel DB di cui NH non sa nulla. Mancherà nella sessione corrente. (Che potrebbe portare a risultati imprevisti)
• di solito non sanno nulla della tua sessione (ad esempio: nome di accesso).

NHibernate intercettori/eventi

• non sono specifico DBMS.
• consentono un facile accesso alle informazioni aziendali voi, come la sessione utente, il nome del computer client, certi calcoli o interpretazioni, localizzazione, ecc
• si consente la configurazione dichiarativa, come attributi nei confronti del soggetto, che definiscono se le esigenze di entità da registrare e come.
• consente di disattivare la registrazione, questo potrebbe essere importante per aggiornamenti, importazioni, azioni speciali che non vengono attivate dall'utente.
• consente di visualizzare un'entità sul modello di business. Probabilmente sei più vicino al punto di vista degli utenti.

Answer 2

io non riesco a pensare a una buona ragione per non usare database trigger per controllare le modifiche al database. Inserti, aggiornamenti ed eliminazioni possono potenzialmente colpire il database da varie fonti: i trigger cattureranno tutto ciò; Hibernate ecc non lo farà.

Answer 3

I tink quando si considera l'auditing, è necessario considerare a cosa serve. In primo luogo, è necessario avere una registrazione di chi ha cambiato cosa e cosa è cambiato in modo da poter annullare i brutti cambiamenti, è possibile identificare i problemi con il sistema (possiamo vedere quale delle diverse applicazioni ha identificato il cambiamento che aiuta a identificare rapidamente quale si è rotto) e così puoi identificare chi ha apportato il cambiamento. L'ultimo può essere davvero critico quando si tratta di individuare le frodi. Se fai tutto dall'interfaccia utente, non vedrai mai l'utente che commette frodi che cambia i dati nel back-end per scrivere un assegno. Se fai tutto dall'interfaccia, probabilmente devi avere le autorizzazioni impostate a livello di tabel, aprendo così la porta alla frode per cominciare. Se fai tutto dall'interfaccia non saprai quale dipendente scontento ha cancellato l'intera tabella utente per il puro valore di fastidio. Se fai tutto dal front end non saprai quale dba incompetente ha accidentalmente aggiornato tutti gli ordini dei clienti allo stesso cliente. Non posso supportare l'utilizzo di qualsiasi cosa tranne i trigger per l'auditing in quanto perdi una buona parte del motivo per cui hai bisogno di auditing in primo luogo.

Answer 4

L'utilizzo di intercettatori Hibernate per eseguire i registri di controllo è profondamente errato. Sono sbalordito dal numero di blog che raccomandano questo metodo senza evidenziare il suo difetto più ovvio: l'intercettatore HA a utilizzare una nuova transazione per registrare l'audit. Ciò significa che è possibile salvare con successo la transazione principale e provocare un arresto anomalo del sistema che non registra la transazione di controllo!

Answer 5

una vecchia questione che mi imbattei now.There è un'opzione più disponibile e che è Envers che è disponibile con Hibernate a partire da ver 3.6 in poi ..

Answer 6

ho capito questo non è correlato al 100% domanda ma aggiunge valore con nuove opzioni.

Ci sono altri due modi per controllare cosa sta succedendo.

Lettura del log delle transazioni: se il database è in modalità di ripristino completo, tutti i dettagli relativi alle istruzioni INSERT, UPDATE, DELETE e DDL vengono registrati nel registro delle transazioni.

problema è che è molto complesso da leggere perché non è supportata in modo nativo e che avrete bisogno di una terza lettura log delle transazioni parti come ApexSQL Log o SQL Log Rescue (quest'ultimo si è liberi, ma supporta solo SQL 2000).

vantaggio di questo metodo è che letteralmente non è necessario apportare modifiche se non per mettere il database in modalità di recupero completo.

SQL Server tracce: Tracce cattureranno tutto in file di traccia tra cui selezionare le dichiarazioni che anche possono essere necessari per alcuni scenari di conformità. Lo svantaggio è che le tracce sono file di testo che devono essere analizzati e organizzati.