Non sono sicuro che esista un "approccio migliore", ci sono così tante variabili da prendere in considerazione, incluso quanto sei lontano nel percorso di sviluppo.
Dopo aver utilizzato soluzioni di auditing basate su codice e db-trigger, ho elencato alcuni commenti di seguito; Spero che tu possa vedere a che punto sei ora (in termini di sviluppo) potrebbe influenzare questi problemi:
- Se hai bisogno di mappare l'utente che ha cambiato i dati (cosa che normalmente fai), allora i trigger db dovranno ottenere queste informazioni in qualche modo. Non impossibile, ma più lavoro e diversi modi per avvicinarsi a questo (db utente che esegue query, colonna utente comune in ogni tabella, ecc.)
- Se utilizzi i trigger db e fai affidamento sul conteggio delle righe interessate restituito dalle query, è necessario che i trigger di controllo siano disattivati o che il codice esistente venga modificato per tenerne conto.
- I trigger IMHO db offrono maggiore sicurezza e offrono un percorso più semplice per l'automazione dell'audit, tuttavia non sono infallibili, poiché chiunque abbia un accesso appropriato può disabilitare i trigger, modificare i dati e quindi riattivarli. In altre parole, assicurati che i tuoi diritti di accesso alla sicurezza del db siano stretti.
- Avere una singola tabella per la cronologia non è un brutto modo, anche se avrai più lavoro da fare (e dati da archiviare) se stai controllando la cronologia per più tabelle, specialmente quando si tratta di ricostruire l'audit trail. Devi anche considerare problemi di blocco se ci sono molte tabelle che tentano di scrivere su una tabella di controllo.
- Avere una tabella della cronologia di controllo per ogni tabella è un'altra opzione. Hai solo bisogno che ogni colonna nella tabella di controllo sia annullabile, oltre a memorizzare la data e l'ora dell'azione (inserimento/aggiornamento/eliminazione) e l'utente associato all'azione.
- Se scegli l'opzione tabella singola, a meno che tu non abbia molto tempo da dedicare a questa, non esagerare nel provare a controllare solo gli aggiornamenti o le eliminazioni, anche se potrebbe essere allettante evitare gli inserimenti (poiché la maggior parte le app lo fanno più spesso degli aggiornamenti o delle eliminazioni), ricostruire la cronologia di controllo richiede un bel po' di lavoro.
- Se i tuoi server o dati coprono più fusi orari, prendi in considerazione l'utilizzo di un tipo di data e ora appropriato per poter archiviare e ricostruire la sequenza temporale, ovvero memorizzare la data dell'evento di controllo in formato UTC e includere l'offset del fuso orario.
- Queste tabelle di controllo possono diventare enormi, quindi adotta una strategia se iniziano a influire sulle prestazioni. Le opzioni includono il partizionamento delle tabelle su dischi diversi, l'archiviazione, ecc. In pratica pensaci ora e non quando diventa un problema :)
