Il modo migliore per progettare un database e una tabella per tenere traccia delle modifiche?

16

Devo impostare una funzione di cronologia su un progetto per tenere traccia delle modifiche precedenti.

Diciamo che ho due tavoli in questo momento:

NOTES TABLE (id, userid, submissionid, message)

SUBMISSIONS TABLE (id, name, userid, filepath)

Esempio: ho una riga nelle note e l'utente vuole cambiare il messaggio. Voglio tenere traccia del suo stato prima della modifica e dopo la modifica.

Quale sarebbe l'approccio migliore per impostare una colonna in ciascuna di queste tabelle che dirà se un elemento è "vecchio". 0 se attivo OPPURE 1 se eliminato / invisibile.

Voglio anche creare una AUDIT TRAILtabella history ( ) che contenga lo idstato precedente, idil nuovo stato, a quale tabella si riferiscono questi ID?

mysql database-design audit

— Schwarz
fonte

1

È possibile utilizzare i trigger del database per creare una tabella di controllo .

— Kin Shah,

5

Si prega di visualizzare

http://www.codeproject.com/Articles/105768/Audit-Trail-Tracing-Data-Changes-in-Database

È un'ottima lettura degli approcci per creare un Audit Trail nella progettazione del database. Gli audit trail sono necessari per l'implementazione di un database. Dovresti sempre essere in grado di vedere le azioni degli utenti del database all'interno del sistema.

Siamo in grado di tenere traccia delle righe modificate nel nostro sistema PTA (Point in Time) aggiungendo alcune colonne PTA (point in time) standard a tutte le tabelle di interesse PTA.

Suggerisco quanto segue:

DateCreated – the actual date on which the given row was inserted.
DateEffective – the date on which the given row became effective.
DateEnd – the date on which the given row ceased to be effective.
DateReplaced – the date on which the given row was replaced by another row.
OperatorCode – the unique identifier of the person (or system) that created the row.

— ettore
fonte

qual è il modo migliore per applicare la "soluzione n. 2: tabella di tracciabilità dei dati dedicata" per un'applicazione OLTP.

— AA.SC,

La società per cui lavoro attualmente utilizza più schemi, uno specifico per l'audit trail. La tabella di audit è davvero una progettazione piuttosto semplice quando si utilizza la soluzione n. 2 (che è esattamente ciò che utilizziamo qui al lavoro). Suddividere le diverse attività (tabella di inventario aggiornata, informazioni sui clienti aggiornate o cancellate, crediti forniti al cliente, ecc. Ecc.) E costruire la tabella di audit in base alle azioni comuni di cui gli utenti sono in grado. Risponde alla tua domanda sull'applicazione della soluzione 2 al tuo db, in caso contrario chiarisci. Grazie!

— Ettore,

In realtà stiamo già controllando i dati con il primo approccio usando le tabelle di audit, ma i dati di audit stanno diventando così enormi e ora vogliamo convertire il nostro approccio semplicemente acquisendo dati contro colonne modificate. La mia domanda è: come posso raggiungere questo approccio? qual è il modo migliore per tracciare quale colonna della tabella è cambiata? .. se una tabella ha più di 20 colonne, una di esse è con DataType Text.

— AA.SC,

10

Quando si progettano funzionalità di controllo della versione nei dati, ci sono diversi requisiti minimi (credo):

Ogni versione dei dati dovrebbe essere autonoma e indipendente dalle altre versioni. Ciò significa che nessun flag o altro indicatore mostra quale sia la versione corrente e quali siano "cronologia". Significa anche aggiornare l'entità significa inserire solo una nuova versione - non è necessario alcun aggiornamento delle versioni precedenti.
Evita ciò che chiamo Row Spanning Dependency. È qui che un campo (End_Date) di una riga deve rimanere sincronizzato con un altro campo (Start_Date) di una riga diversa. Ciò rende più difficile il lavoro con i dati ed è un'ottima fonte di anomalie.
La versione corrente e tutte le versioni precedenti dovrebbero essere nella stessa tabella. Ciò consente di utilizzare la stessa query per visualizzare i dati passati "a partire da" una data particolare e visualizzare i dati correnti.
Le chiavi esterne per i dati che sono stati sottoposti a versione dovrebbero funzionare allo stesso modo dei dati normali (senza versione).
Il design dovrebbe essere così semplice o universalmente compreso da ridurre al minimo la curva di apprendimento per i nuovi sviluppatori.

Ecco le slide di una presentazione che ho fatto alcune volte alle fiere tecnologiche. Descrive come si può fare tutto quanto sopra. Ed ecco un documento che approfondisce. Devo scusarmi per il documento: è un lavoro in corso e non tutte le sezioni sono completate. Ma dovrebbe darti tutte le informazioni necessarie per implementare qualsiasi cosa, dal semplice controllo delle versioni all'accesso bidimensionale completo.

— TommCatt
fonte

1

Punti molto belli! Tuttavia, non capisco bene questo This means no flag or other indicator showing which is the current version and which are "history.", se non ci sono flag o indicatori, in che modo differenziamo la versione corrente da quella storica? Soprattutto in base al terzo punto che suggerisci che dovrebbero essere nella stessa tabella.

— GMsoF,

La presentazione mostra un disegno di esempio, inclusa la query per leggere i dati attuali e / o passati dalle tabelle. Se sembra abbastanza interessante da approfondire, il documento contiene molti più dettagli.

— TommCatt,