Strategie di registrazione degli audit

Question

Sto cercando di decidere il metodo migliore per la registrazione di controllo all'interno della mia applicazione. Il motivo principale del registro è la sequenza degli eventi (modifiche).

Ho una gerarchia di oggetti, ho bisogno di creare report quando qualcosa cambia in qualsiasi parte di quella gerarchia, in una data successiva.

Penso di avere tre opzioni:

1. Avere un registro per ogni tabella e quindi abbinare la gerarchia degli oggetti, quindi creare una vista per il rapporto.
2. Appiattire la gerarchia e de-normalizzare la tabella, semplificando la creazione di report: semplice istruzione select.
3. Dispone di una tabella di registro e di un record per ogni modifica che rende i rapporti più difficili ma più flessibili alle modifiche.

Attualmente mi sto avvicinando all'opzione 1.

Answer 1

Un registro di controllo è sostanzialmente un elenco cronologico degli eventi che si sono verificati, che hanno eseguito questi eventi e quali erano gli eventi.

Penso che una vista piatta sarebbe migliore in quanto può essere facilmente ordinata e interrogata. Quindi sono più incline alla tua opzione n. 2 / n. 3.

Includi elementi come il tipo di transazione, l'ora, l'ID utente, una descrizione di ciò che è cambiato e altre informazioni pertinenti relative al tuo prodotto.

È inoltre possibile aggiungere elementi al prodotto nel tempo e non sarà necessario modificare continuamente il modulo del registro di controllo.

Answer 2

Devo parlare di questo argomento anche se è vecchio.

Di solito è una cattiva idea avere una sola tabella di controllo poiché si creeranno problemi di blocco nel database quando tutto colpisce quella tabella. Utilizzare tabelle di controllo separate per ogni tabella.

È inoltre una cattiva idea fare in modo che l'applicazione esegua il controllo. Il controllo deve essere eseguito a livello di database o si rischia di perdere alcune delle informazioni. I dati non cambiano solo dalle applicazioni nella maggior parte dei database; nessuno cambierà i prezzi di tutti i loro prodotti uno alla volta dall'interfaccia utente quando è necessario un aumento del 10% a tutti i 10.000.000 di essi. Il controllo dovrebbe acquisire tutte le modifiche, non solo alcune. Questo dovrebbe essere fatto in un trigger nella maggior parte dei database (SQL Server 2008 ha una funzione di controllo integrata). Alcuni dei peggiori possibili cambiamenti possibili (dipendenti che commettono frodi o che vogliono distruggere i dati in modo dannoso) provengono spesso anche da luoghi diversi dall'applicazione, specialmente se si consente l'accesso a livello di tabella agli utenti (cosa che non si dovrebbe fare in alcun database finanziario o che contenga informazione personale). Il controllo dall'applicazione non lo rileva. Gli sviluppatori spesso dimenticano che nel proteggere i loro dati, le fonti esterne non sono l'unica minaccia.

Answer 3

Se è a scopo di controllo, utilizzerei un vero supporto di sola aggiunta anziché una tabella / tabelle nello stesso db.

Suggerisci che è a fini di cronologia delle modifiche, nel qual caso ristrutturerei la tua applicazione / db per registrare gli eventi effettivi in ??primo luogo anziché solo lo stato corrente.

Answer 4

Vorrei andare con (2) e (3): creare una singola tabella per tutte le voci di controllo.

Una vista piatta è buona, a condizione che l'appiattimento extra del lavoro non influisca sulle prestazioni.

Answer 5

Potresti esaminare un framework AOP per aiutarti. Ti consentirebbe di inserire la funzionalità di registrazione all'inizio o alla fine di qualsiasi / tutti i metodi. Se segui questa strada, potrebbe essere utile definire cosa avrebbe senso archiviare i dati del registro.