Audit Trigger: Usa inserita o tabelle di sistema DELETED

Question

Il tema di come controllare le tabelle è recentemente sorto nelle nostre discussioni ... quindi mi piace il tuo parere su che cosa è il modo migliore per affrontare questo. Abbiamo un mix di entrambi gli approcci (che non è buono) nel nostro database, in quanto ogni DBA precedente ha fatto quello che lui / lei credeva fosse la strada giusta. Quindi abbiamo bisogno di cambiare loro di seguire qualsiasi modello.

CREATE TABLE dbo.Sample(
Name VARCHAR(20),
...
...
Created_By VARCHAR(20),
Created_On DATETIME,
Modified_By VARCHAR(20),
Modified_On DATETIME
)

CREATE TABLE dbo.Audit_Sample(
Name VARCHAR(20),
...
...
Created_By VARCHAR(20),
Created_On DATETIME,
Modified_By VARCHAR(20),
Modified_On DATETIME
Audit_Type VARCHAR(1)  NOT NULL
Audited_Created_On DATETIME
Audit_Created_By VARCHAR(50)
)

Approccio 1: Store, in tabelle di controllo, solo i record che vengono sostituiti / cancellati dalla tabella principale (con tabella di sistema CANCELLATO). Quindi per ogni UPDATE e DELETE nella tabella principale, il record da sostituire viene inserita nella tabella di controllo con la colonna 'Audit_Type' come appassire 'U' (per UPDATE) o 'D' (per DELETE)

Gli inserti non sono oggetto di revisione contabile. Per la versione attuale di qualsiasi record che sempre esegue una query la tabella principale. E per la storia si esegue una query tabella di controllo.

Pro: Sembra intutive, per memorizzare le versioni precedenti di record Contro: Se avete bisogno di conoscere la storia di un record particolare, è necessario unire tabella di controllo con tabella principale

.

appraoch 2:. Store, nella tabella di controllo, tutti i record che va in tabella principale (con tabella di sistema INSERITA)

Ogni record che viene inserito / AGGIORNATO / cancellati per tabella principale è anche memorizzato nella tabella di controllo. Così, quando si inserisce un nuovo record è anche inserito nella tabella di controllo. Quando aggiornata, la nuova versione (da inserita) tabella è memorizzato nella tabella di revisione. Dopo l'eliminazione vecchia versione (da CANCELLATO) tabella è memorizzato nella tabella di controllo.

Pro: Se avete bisogno di conoscere la storia di un particolare record, avete tutto in un unico luogo

.

Anche se non ho elencare tutti qui, ogni approccio ha i suoi pro e contro?

Answer 1

mi piacerebbe andare con:

  

appraoch 2: Store, nella tabella di controllo, tutti i record che va in tabella principale   (Utilizzando la tabella di sistema INSERITA).

è una riga in più per ogni elemento davvero intenzione di uccidere il DB? In questo modo si ha la storia completa insieme.

Se spurgare le righe (una gamma tutti più grandi di giorno X) si può ancora dire se qualcosa è cambiato o no:

• se esiste una riga di controllo (non depurato) si può vedere se la riga in questione ha cambiato.
• se non esistono le righe di controllo per la voce (tutti sono stati epurati) nulla è cambiato (dal momento che ogni cambiamento scrive nella tabella di controllo, tra cui gli articoli completamente nuovi)

se si va con appraoch 1:. Ed eliminare una serie, sarà difficile (bisogno di ricordare la data di spurgo) per raccontare nuovi inserti contro quelli in cui sono stati eliminati tutti i file

Answer 2

Un terzo approccio che usiamo un sacco è quello di controllare solo le colonne interessanti, e salvare entrambi e valore 'nuovo' 'vecchio' in ogni riga.

Quindi, se avete la vostra colonna "nome", la tabella di controllo avrebbe "name_old" e "name_new".

In trigger INSERT, "name_old" è impostato a vuoto / null a seconda delle preferenze e "name_new" è impostato dal inseriti. In trigger UPDATE, "name_old" è impostato da cancellate e "name_new" da INSERITO In trigger DELETE, "name_old" è impostato dalla cancellata e "NEW_NAME" a vuoto / null.

(o si utilizza un join completa e un trigger per tutti i casi)

Per i campi VARCHAR, questo potrebbe non sembrare una buona idea, ma per INTEGER, DATETIME, ecc fornisce il vantaggio che è molto facile vedere la differenza dell'aggiornamento.

vale a dire. se si dispone di un quantitativo di campo nella tabella reale e aggiornarlo 5-7, devi avere nella tabella di controllo:

quantity_old  quantity_new
           5             7

facilmente si può calcolare che la quantità è stato aumentato di 2 sul tempo specifico.

Se si dispone di righe separate nella tabella di controllo, si dovrà aderire a una riga con "il prossimo" per calcolare la differenza - che può essere difficile in alcuni casi ...