Audit trail e azioni di registrazione

Should we tailor the audit log tables to fit the requirements of the front end?

No. In genere, è meglio quando si personalizzano le tabelle del registro di controllo in modo da soddisfare i requisiti degli auditor e quindi preoccuparsi del front-end in un secondo momento.

Should we have separate tables to handle the "Actions" and have the events and auditing separate

Sì. Ciò ti dà un maggiore controllo sugli eventi e ne aggiunge di nuovi quando ti servono.

Should we look to a more message based architecture so this will be more like an Event sourcing type component?

Preferisco mantenere le cose semplici e archiviare semplicemente nel db. Tuttavia, un'architettura basata su messaggi può funzionare bene se si sta integrando in un'applicazione multilivello e il codice è da qualche parte nel middleware. Ma qui dipende da cosa hai bisogno e dovremmo parlare di requisiti più specifici di quelli che abbiamo qui.

Se si è consapevoli del fatto che le azioni esterne all'applicazione non verranno registrate (personalmente non proverei a fare il controllo eccetto tramite i trigger, ma i prodotti di terze parti sono di solito un problema separato perché si ha una capacità limitata di cambiare il db stesso.), l'approccio è OK.

Ciò che è generalmente necessario nel controllo è un approccio in cui si memorizzano in tabelle separate per ogni tabella controllata (per evitare che la tabella di controllo causi blocchi). Quindi memorizzi ciò che devi sapere per ripristinare i dati e trovare il colpevole se il cambiamento è un problema e ciò che un auditor vorrà sapere.

Quindi memorizziamo sia i vecchi che i nuovi valori, archiviamo l'id della persona che ha apportato le modifiche e il nome dell'applicazione che ha inviato la modifica (Abbiamo più applicazioni che colpiscono lo stesso database) e memorizziamo anche il datetime di il cambiamento (molto critico nel trovare tutti i record th3 che devono essere ripristinati da una cattiva spinta di produzione avvenuta il 02/01/2013 a mezzanotte).

Perché le nostre modifiche sono spesso in gruppi e non solo un record alla volta, ogni tabella di controllo viene anche divisa in una tabella che memorizza le informazioni sull'inserimento / aggiornamento o sull'eliminazione (data / ora, persona, applicazione, tipo di modifica ) e uno che memorizza i record specifici modificati o inseriti o cancellati. In tal modo, se trovi una modifica errata del record, puoi vedere se ci sono stati altri record modificati dalla stessa persona o applicazione allo stesso tempo.

Mentre stai progettando il sistema, vai avanti e scrivi lo sql necessario per ripristinare i dati nel suo vecchio formato. Anche se non intendi usare l'auditing per questo, c'è una probabilità del 100% che tu la usi in quel modo una volta che i dati sono lì. Sionce che di solito accade sotto rpessure, è meglio avere uno script o stored proc pronto per il ripristino dei dati.