Tabella cronologica database / tabella di tracciamento

Attualmente voglio strutturare una tabella di tracciamento / cronologia come questa:

• PrimaryKey - ID
• AltroTableId - fk
• fieldName: nome del campo da tracciare
• OldValue
• NewValue
• Nome utente
• CreateDateTime

Quindi sostanzialmente voglio avere una tabella che segua la cronologia di un'altra tabella, memorizzare il nome della colonna del campo modificato con il nuovo e il vecchio valore. La mia domanda è: qualcuno può creare buchi in questo? Inoltre, qual è il modo più semplice per garantire che nella colonna fieldName sia inserito solo un nome di colonna dalle tabelle di cui tiene traccia? Attualmente le mie opzioni sono avere un enum nel servizio che sto costruendo, o creare un'altra tabella di stato e rendere fieldName un fk. Qualche idea migliore?

Modifica obiettivo: al momento ci sono solo 2 campi che ci interessa monitorare. Un campo verrà mostrato su una pagina Web per visualizzare la cronologia, l'altro campo sarà accessibile solo da un dipartimento e avranno accesso a una vista del database che potrebbero interrogare. Avrebbero cercato solo questo campo per ottenere informazioni su chi ha cambiato il campo e cosa fare. Questo è il motivo per cui volevamo impostarlo dove un campo di database definisce la colonna della tabella anziché avere una copia esatta della cronologia dei record della tabella. Vogliamo solo tenere traccia di due campi con la possibilità di aggiungere o rimuovere campi in futuro.

Grazie!

Colpire i buchi: cosa succede se lo schema del database viene modificato nello stesso punto in un secondo momento, e il nome di una colonna cambia o la colonna viene eliminata completamente? Molti sistemi di database lo consentono. Cosa succederà al tuo "fieldName" allora?

Per integrità dei dati: è necessario assicurarsi che ogni operazione di aggiornamento o eliminazione aggiornerà sicuramente la tabella di monitoraggio. Ciò si ottiene meglio con i trigger che chiamano una procedura memorizzata. È necessario assicurarsi che solo le procedure memorizzate abbiano accesso in scrittura alla tabella di monitoraggio, in modo che nessun altro possa scrivere valori errati.

Se riesci a convivere con una soluzione specifica del fornitore db: la maggior parte dei sistemi db ha tabelle di sistema in cui sono archiviate le informazioni sullo schema (nomi delle tabelle, ID delle tabelle, nomi delle colonne, ecc.). È possibile verificare se è possibile impostare un riferimento di chiave esterna a tale tabella di sistema. Ciò consentirebbe di sostituire il nome del campo con un ID campo se il database supporta qualcosa del genere.

In realtà, se devi tenere traccia di intere righe della tabella specifica, comprese tutte le colonne (e non solo un piccolo sottoinsieme delle colonne), dovresti considerare il suggerimento di @ sarfeast. Leggi questo articolo sugli svantaggi dei modelli nome-valore-coppia.

L'implementazione di audit delle modifiche (tracking della cronologia) di maggior successo che ho visto è meno generica e molto più semplice. Implica la creazione di una tabella del registro delle modifiche per ciascuna tabella che si desidera monitorare, mantenendo nomi di colonna e tipi di dati identici (con una colonna aggiuntiva per il timestamp).

L'obiettivo finale, ovvero cosa ti piacerebbe fare con i dati controllati, ti aiuterà a valutare l'adeguatezza di ciascun approccio.

In breve: è necessario impostare il meccanismo Audit Trail per le tabelle in cui si desidera tenere traccia della modifica del valore.

Tabella delle singole tracce di audit :

Creare una tabella per registrare il nome della tabella, il nome del campo e le versioni vecchie e nuove dei dati. Per questo metodo è normale registrare sia la vecchia che la nuova versione dei dati e solo quei campi che sono stati modificati. Per implementare questo nei trigger, è necessario che sia presente una chiave primaria nella tabella o che vengano aggiornate solo le singole righe.

Ecco un buon post con script su come raggiungerlo: la creazione di audit trail

Altri riferimenti utili da guardare:

• Audit trail: traccia delle modifiche dei dati nel database
• Lasciando una traccia di controllo nel database

Si consiglia di consultare la documentazione del progetto NHibernate Envers per idee.

Fondamentalmente, hai una tabella di revisione in cui puoi aggiungere dati extra come un timestamp o un utente. Quindi, ogni tabella tracciata ottiene una tabella di controllo aggiuntiva con tutte le colonne duplicate, un fk nella tabella di revisione e il tipo di revisione (aggiungi, modifica, elimina). AFAIK, non vorrai che le tue tabelle di controllo abbiano un FK effettivo nella tabella reale perché ciò impedirebbe le eliminazioni.