Database - Versioning dati

Question

Ho letto alcune domande su SO (ad esempio this one) in merito al controllo delle versioni dei dati in un database.

Mi sono piaciuti alcuni dei suggerimenti menzionati. Ho avuto il tempo più lungo desiderato (necessario) per revisionare molti dei miei tavoli, ma non ci sono mai riuscito. Essendo un programmatore con solo un semplice database lavoro sotto la cintura mi chiedevo come si sarebbe effettivamente andare a fare questo.

Non sto chiedendo la soluzione reale nella sintassi SQL. Finalmente posso capirlo da solo (o postare SO quando arriverà il momento). Sto solo chiedendo alla gente di commentare come farebbero per farlo e qualsiasi potenziale problema di prestazioni ci potrebbe essere se dovessi "revisionare" centinaia di milioni di record. O qualsiasi altro suggerimento purché sia ​​basato sull'esempio qui sotto.

dato un semplice esempio:

Person 
------------------------------------------------ 
ID    UINT NOT NULL, 
PersonID   UINT NOT NULL, 
Name    VARCHAR(200) NOT NULL, 
DOB    DATE NOT NULL, 
Email    VARCHAR(100) NOT NULL 

Audit 
------------------------------------------------ 
ID    UINT NOT NULL, 
UserID   UINT NOT NULL,    -- Who 
TableName   VARCHAR(50) NOT NULL,  -- What 
OldRecID   UINT NOT NULL,    -- Where 
NewRecID   UINT NOT NULL, 
AffectedOn  DATE NOT NULL,    -- When 
Comment   VARCHAR(500) NOT NULL  -- Why 

Non sono sicuro di come si potrebbe collegare la tabella di verifica per tutti gli altri tavoli (come persona) se il TableName è una stringa?

Inoltre, partendo dal presupposto che ho tre GUI per popolare:

1. Una scheda completa per una persona specifica id
2. Una vista tabella che elenca tutte le persone (da id)
3. Una vista che mostra ogni persona con le loro informazioni di revisione sotto ciascuna voce (numero di revisioni per persona, date delle revisioni, commenti di revisione, ecc.) ordinate dalle revisioni più recenti.

Per eseguire 1 e 2, sarebbe meglio interrogare la tabella Persona o la tabella di controllo?

Per realizzare 3, un cosiddetto esperto di database otterrebbe semplicemente tutti i record e li inoltrerà al software per l'elaborazione, o raggrupperà per Persona e Data interessata? Di solito questo è gestito in una query o in molti?

Answer 1

ho fatto vari sistemi di audit nel corso degli anni e sono attualmente in corso di implementare qualcosa di simile:

Person 
------------------------------------------------ 
ID    UINT NOT NULL, 
PersonID   UINT NOT NULL, 
Name    VARCHAR(200) NOT NULL, 
DOB    DATE NOT NULL, 
Email    VARCHAR(100) NOT NULL 


Person_History 
------------------------------------------------ 
ID    UINT NOT NULL, 
PersonID   UINT NOT NULL, 
Name    VARCHAR(200) NOT NULL, 
DOB    DATE NOT NULL, 
Email    VARCHAR(100) NOT NULL 
AuditID   UINT NOT NULL 


Audit 
------------------------------------------------ 
ID    UINT NOT NULL, 
UserID   UINT NOT NULL,    -- Who 
AffectedOn  DATE NOT NULL,    -- When 
Comment   VARCHAR(500) NOT NULL  -- Why 

Le registrazioni attuali sono sempre nella tabella persona. Se c'è una modifica viene creato un record di controllo e il vecchio record viene copiato nella tabella Person_History (notare che l'ID non cambia e possono esserci più versioni)

L'ID di controllo si trova nelle tabelle * _Storia in modo da poter collega più modifiche ai record a un record di controllo, se lo desideri.

MODIFICA:
Se non si dispone di una tabella della cronologia separata per ogni tabella di base e si desidera utilizzare la stessa tabella per conservare i record vecchi e "eliminati", è necessario contrassegnare i record con un flag di stato. Il problema con questo è un vero dolore quando si eseguono query per i record correnti: credetemi, l'ho fatto.

Answer 2

In seguito al post di DJ sull'utilizzo di una tabella di cronologia per tabella di base e un commento di Karl sui possibili problemi di prestazioni, ho svolto un po 'di ricerche SQL per trovare il modo più veloce per trasferire un record da una tabella ad un altro.

Volevo solo a documentare quello che ho trovato:

ho pensato che avrei dovuto fare uno SQL recuperare per caricare il record dalla tabella di base, seguito con una spinta SQL per mettere il record nella tabella storia , seguito da un aggiornamento alla tabella di base per inserire i dati modificati. Totale di 3 transazioni.

Ma con mia sorpresa mi sono reso conto che è possibile eseguire le prime due transazioni utilizzando un'istruzione SQL utilizzando la sintassi SELECT INTO. Sto scommettendo che le prestazioni sarebbero cento volte più veloci.

Quindi questo ci lascerebbe semplicemente AGGIORNARE il record con i nuovi dati all'interno della tabella di base.

Non ho ancora trovato una dichiarazione SQL per eseguire tutte e 3 le transazioni contemporaneamente (dubito che lo farò).

Answer 3

Che ne dici di creare la tabella come di consueto, avere una colonna ModifiedDate su ogni record (e ModifiedBy se ti piace), e fare tutti i tuoi dati di accesso attraverso una vista materializzata che raggruppa i dati per Id e poi fa un HAVING ModifiedDate = MAX (ModifiedDate)?

In questo modo, l'aggiunta di un nuovo record con lo stesso ID di un altro rimuoverà il vecchio record dalla vista. Se si desidera interrogare la cronologia, non passare attraverso la vista

Ho sempre trovato la manutenzione di tabelle diverse con le stesse colonne per essere complesse e soggette a errori.

Answer 4

Mi piace la tua tabella di controllo, è un buon inizio. Hai un problema con il vostro cardinalità tabella di controllo, quindi vorrei busto fuori come due tabelle:

Person 
------------------------------------------------ 
ID    UINT NOT NULL, 
PersonID   UINT NOT NULL, 
Name    VARCHAR(200) NOT NULL, 
DOB    DATE NOT NULL, 
Email    VARCHAR(100) NOT NULL, 
AuditID   UINT NOT NULL 

Audit 
------------------------------------------------ 
ID    UINT NOT NULL, 
TableName   VARCHAR(50) NOT NULL,  -- What 
TableKey   UINT NOT NULL, 
CreateDate  DATETIME NOT NULL DEFAULT(NOW), 
CreateUserID  UINT NOT NULL, 
ChangeDate  DATETIME NOT NULL DEFAULT(NOW), 
ChangeUserID  UINT NOT NULL 

Audit_Item 
------------------------------------------------ 
ID    UINT NOT NULL, 
AuditID   UINT NOT NULL,    -- Which audit record 
UserID   UINT NOT NULL,    -- Who 
OldRecID   UINT NOT NULL,    -- Where 
NewRecID   UINT NOT NULL, 
AffectedOn  DATE NOT NULL,    -- When 
Comment   VARCHAR(500) NOT NULL  -- Why 

Il layout iniziale proposto ha un singolo record di audit che punta a (presumo) due record Persona. Le sfide di questo design sono:

• Quali record nella tabella di persona sono i record "reali" correnti?
• Come si rappresenta l'intera cronologia delle modifiche al record Persona? Se stai puntando a due record nella tabella Persona, quindi vedi il punto 1: quale è il record corrente?
• I campi Crea *, Cambia * sono arrotolati da una raccolta di record Audit_Item . Sono lì solo per la facilità di accesso .
• La chiave AuditID nella tabella persona consente di puntare di nuovo al tavolo Audit e arriva a la storia della singola persona senza bisogno di interrogare la tabella di controllo con la clausola WHERE TableName='Person'