Strategia di controllo versione generica per dati tabella selezionati all'interno di un database fortemente normalizzato

Question

Ci scusiamo per il titolo con ventaglio lungo, ma il requisito/problema è piuttosto specifico.

Con riferimento alla seguente struttura di esempio (ma molto semplificata) (in psuedo SQL), spero di spiegarlo un po 'meglio.

TABLE StructureName { 
    Id GUID PK, 
    Name varchar(50) NOT NULL 
} 

TABLE Structure { 
    Id GUID PK, 
    ParentId GUID,     -- FK to Structure 
    NameId GUID NOT NULL   -- FK to StructureName 
} 

TABLE Something { 
    Id GUID PK, 
    RootStructureId GUID NOT NULL -- FK to Structure 
} 

Come si può vedere, struttura è una semplice struttura ad albero (non è preoccupato per l'ordinazione dei bambini per il problema). StructureName è una semplificazione di un sistema di traduzione. Infine "Qualcosa" è semplicemente qualcosa che fa riferimento alla struttura radice dell'albero.

Questa è solo una delle molte tabelle che devono essere sottoposte a versionamento, ma questa rappresenta un buon esempio per la maggior parte dei casi.

Esiste un requisito per la versione di eventuali modifiche al nome e/o al "layout" dell'albero della tabella Struttura. Le versioni precedenti dovrebbero essere sempre disponibili.

Sembra esserci qualche possibilità per affrontare questo problema, come copiare l'intera struttura, ma la maggior parte degli approcci fa sì che si possa "perdere" l'integrità referenziale. Esempio se si seguisse questo approccio, si dovrebbe fare un duplicato del record 'Something', dato che la struttura radice sarà un nuovo record e avrà un nuovo ID.

Altre strade di possibili soluzioni stanno esaminando come Wiki gestisce questo o molto più lontano e guarda come funzionano i sistemi di controllo versione.

Attualmente, mi sento un po 'all'oscuro come procedere su questo in modo generico.

Tutte le idee saranno molto apprezzate.

Grazie

leppie

Answer 1

Alcune idee veloci:

copia completa: Creare una copia della struttura, ma per ogni tavolo aggiungere una colonna version_id alla PK e tutti FKS; quindi è possibile creare copie dei dati di vita con integrità referenziale completa.

• Pro: facile da interrogare la storia
• con: grandi quantità di (dati ridondanti copiati)

Cambio copia: unica copia la roba che cambia in realtà, insieme a valid_from/valid_to dati.

• pro: basso volum dati copiati
• con: difficile da interrogare, perché si ha a unirsi a intervalli

Variante: Questo vale per entrambi gli schemi. Invece di creare una copia della struttura, potresti tenere il record corrente nella stessa tabella delle vecchie versioni, ma taggarlo come corrente.

• pro: più piccolo numero di tavoli, più semplice miscelazione di storia e di informazioni aggiornate
• con: funzionamento normale opera su tavoli molto più grandi, che causeranno un impatto sulle prestazioni

registro di controllo: A seconda delle esigenze effettive, è sufficiente creare un audit trail come questo:

id, timestamp, changed_table, changed_column, old_value, new_value, changed_by 

Si potrebbe estendere tale ad una struttura completa della tabella:

transaction, table_change, changed_column 

• pro: generico, e quindi facile da implementare per un gran numero di tavoli
• con: se avete bisogno di ricostruire lo stato di una serie di record in un dato momento, l'interrogazione diventerà un incubo

Ho scritto a blog about various approaches to versioning, ma attenzione: è in tedesco.

Answer 2

Gli addetti data warehouse hanno diversi algoritmi per "dimensioni cambiano lentamente".

Gli algoritmi più sofisticati forniscono intervalli di dati attorno a un valore di dimensione per indicare quando è valido.

A seconda dei requisiti di versione, è possibile eseguire una di queste operazioni, caricate dal kit di strumenti di data warehousing di Kimball.

1. Assegnare un numero di versione alle righe della tabella della struttura. Ciò significa che devi fare qualche ragionamento per raccogliere una struttura completa. Include il numero di versione selezionato unito a righe che sono rimaste invariate in una versione precedente.

2. Assegnare un intervallo di date o un intervallo di versione alle righe della tabella della struttura. Ciò significa che alcune righe hanno date di inizio e date di fine; alcune file avranno date di fine in qualche epoca nel futuro impossibile. Oppure, se si utilizzano i numeri di versione, si avrà una coppia start-end o una coppia start-infinity che indica che questa riga è ancora attuale. È quindi possibile interrogare banalmente le righe che sono valide "oggi" o applicare alla versione richiesta.

3. Clona la struttura per ogni versione. Questo spiacevole perché l'operazione di clonazione è costosa. Tuttavia, le query sono banali perché l'intera struttura è disponibile con un numero di versione singolo e coerente.