Come faccio a utilizzare un itinerario di controllo per visualizzare i campi sono mai stati modificati?

Question

Per un progetto cui sto lavorando, mi è stato chiesto di creare un itinerario di controllo di tutte le modifiche che sono state apportate al record. Questa è la prima volta che ho dovuto creare una pista di controllo, così ho fatto un sacco di ricerche sull'argomento.

L'applicazione sarà sviluppata in PHP / MSSQL, e sarà a basso traffico.

Dalla mia lettura, ho praticamente deciso di avere una tabella di audit e utilizzare i trigger per registrare le modifiche nella tabella.

I due requisiti per la visualizzazione nella domanda sono i seguenti:

1. Essere in grado di vedere un registro di tutte le modifiche apportate a un campo (ho praticamente so come fare questo)

2. Essere in grado di vedere, durante la visualizzazione di un record nella domanda, un indicatore accanto a qualsiasi campo nel record che sia mai stato cambiato (ed eventualmente altre informazioni come la data dell'ultima modifica).

Articolo # 2 è quello che attualmente mi dà dolore. Senza fare una query separata per ogni campo (o un tempo molto lungo di query nidificate che prenderà le età per l'esecuzione), qualcuno ha suggerimenti per un modo ottimale per fare questo? (Ho pensato di aggiungere un campo aggiuntivo "ModifiedFlag" per ogni campo della tabella, che agirà come indicatore booleano se il campo è mai stato modificato, ma che sembra come un sacco di spese generali.

Answer 1

Vorrei trattare le informazioni di controllo separatamente dal informazioni effettive dominio il più possibile.

Requisito 1: Penso che creare tabelle di revisione supplementari per registrare le modifiche. Eric suggerimento è una buona, creando le informazioni di controllo utilizzando i trigger nel database SQL. In questo modo l'applicazione non ha bisogno di essere a conoscenza della logica di controllo.

Se il database non supporta trigger, allora forse si sta utilizzando un qualche tipo di persistenza o di livello di database. Questo sarebbe anche un buon posto per mettere questo tipo di logica, come ancora una volta a ridurre al minimo eventuali dipendenze tra normale codice dell'applicazione e il codice di controllo.

Requisito 2: Per quanto riguarda gli indicatori che mostra: non vorrei creare campi booleani nella tabella che memorizza l'attuale. (Questo potrebbe causare tutti i tipi di dipendenze di esistere tra il normale codice dell'applicazione e il tuo traccia di controllo di codice.)

vorrei provare a lasciare che il codice responsabile per la visualizzazione sotto forma anche essere responsabile per la visualizzazione di dati di controllo sul livello di campo. Questo farà sì che interrogazione in testa, ma che è il costo per la visualizzazione di questo ulteriore livello di informazioni. Forse si può ridurre al minimo l'overhead database aggiungendo metadati per le informazioni di controllo che consente un facile recupero.

Alcuni grandi applicazioni enterprisy che io sostengo utilizza più o meno la seguente struttura:

• Una tabella di modifica dell'intestazione corrispondente ad una variazione di un record in una tabella.

I campi:

changeId, changeTable, changedPrimaryKey, userName, dateTime

-. Un campo tabella cambiamento corrispondente a un campo che è cambiato

I campi:

changeId, changeField, oldValue, NewValue

contenuto del campione:

Modifica intestazione:

'1', 'BooksTable', '1852860138', 'AdamsD', '2009-07-01 15:30'

Modifica Articolo:

'1', 'Title', 'The Hitchhiker's Guide to the Gaxaly', 'The Hitchhiker's Guide to the Galaxy'
'1', 'Author', 'Duglas Adasm', 'Douglas Adams'

Tale struttura permette sia facile visualizzazione delle piste di controllo come pure facile reperimento per mostrare gli indicatori desiderati. Una query (inner join nella tabella Intestazione e Articoli) sarebbe sufficiente per recuperare tutte le informazioni da mostrare in un'unica forma. (O anche un tavolo quando si dispone di un elenco di mostrato di Id)

Answer 2

Come requisito flagging generale ha cambiato campo "odori" un po 'strano. Se i record sono ormai vissuto e soggetti a modifiche nel corso del tempo poi alla fine tutti i campi tenderanno a farsi così contrassegnato. Quindi mi domando come qualsiasi utente potrebbe avere senso di una serie di indicatori per campo.

Questa linea di pensiero mi fa sospettare che i dati si memorizzano ha bisogno di essere, come hai descritto, una vera e propria pista di controllo con tutti i cambiamenti registrati, e la prima vera sfida è quella di decidere come informazioni dovrebbe essere presentato al l'utente.

Credo che la vostra idea di preparare un qualche tipo di dati aggregateOfTheAuditTrail è probabile che sia molto utile. La domanda sarebbe è una bandiera sola per ogni record abbastanza? Se l'accesso primario dell'utente è attraverso la lista, allora forse è appena sufficiente per evidenziare i record modificati per dopo il drill-down. O una data dell'ultima modifica del valore di registrazione, in modo che solo i record hanno recentemente cambiato sono evidenziati - tutti di nuovo a quello che reali esigenze dell'utente sono. Trovo difficile immaginare che i record cambiati 3 anni fa sono d'interesse turistico come quelli cambiato la scorsa settimana.

Poi, quando arriviamo al drill-down per un singolo record. Anche in questo caso una bandiera semplice per campo non suona utili (anche se il dominio, le vostre esigenze). Se lo è, allora la vostra idea di sintesi va bene. La mia ipotesi è che una sequenza di modifiche a un campo, e la sequenza di cambiamenti complessivi per la cronaca, sono molto più interessante. Dipendente aveva aumento di stipendio, dipendente trasferito reparto, è stato promosso dipendente = tre eventi di lavoro separati o uno?

Se è necessario qualcosa di più di una semplice bandiera, allora ho il sospetto che non vi resta che tornare l'intero (o recente) traccia di controllo per il record e lasciare che la figura UI fuori come presentare questo.

Quindi, il mio primo pensiero: Una specie di rolling-mantenimento di un resoconto sommario suona come una buona idea. Se necessario mantenuta in thread in background o processi batch. Abbiamo deisgn che per essere utile business senza andare alla pista di controllo completa di volta in volta. Poi per analisi dettagliate che consentono alcuni o tutti del percorso da recuperare.

Answer 3

Personalmente, mi piacerebbe fare il monitoraggio semplice, e la segnalazione funky.

Ogni volta che un utente inserisce un record, si effettua un inserimento nella tabella di controllo per quella tabella

'I', 'Date', 'User', 'Data column1','Data Column2', etc.

Che sta assumendo la struttura delle tabelle non cambia nel tempo (re. La quantità di DataColumns)

Per gli aggiornamenti, basta inserire

'U', 'Date', 'User', 'Data column1', etc

Inserisci ciò che l'utente appena entrato come un aggiornamento.

Poi, dopo l'inserimento e aggiornamento, si avrà la seguente

'I','May 3 2009','BLT','person005','John','Smith','Marketing'
'U','May 4 2009','BLT','person005','John','Smith','Accounting'

Quindi, è solo un rapporto facile dimostrare che la persona record unico 'person005' ha avuto un inserimento e un aggiornamento, in cui è stato aggiornato il loro reparto.

A causa della bassa utilizzo del sistema, con un semplice inserto sulla modifica poi un processo di reporting più complesso non ha intenzione di effettuare prestazioni. Questo stile continuerà a funzionare con i sistemi di traffico più elevati, come il carico supplementare su una modifica è minimo, mentre il carico di lavoro maggiore intensità di riferire i cambiamenti non è fatto spesso come un aggiornamento, in modo che il sistema non cadere.