Progettazione di istantanee in un database transazionale insieme alla versione dei dati di riferimento

Question

Disclaimer: ho letto tutto ciò che posso leggere sull'argomento delle istantanee e del versionismo sia su Stack Overflow che su Internet. Il mio requisito non è il monitoraggio della versione per Audit Trail o le istantanee a livello di database. Ho trascorso più di 1 settimana per ricercare da solo e pensare attraverso le possibili opzioni. Mi dispiace, avrei potuto perdere alcuni link - se la soluzione al mio problema è già discussa in qualche altro thread, ti preghiamo di indicarmi lì.

È un po 'lungo; Per favore, abbi pazienza con me.

Ecco la situazione: stiamo cercando di creare un design generico per archiviare istantanee dei dati transazionali nel nostro database transazionale e anche per mantenere una cronologia di revisione dei dati di riferimento.

Come parte del processo aziendale, un utente può premere un pulsante per pubblicare un determinato oggetto. Ai fini dell'illustrazione, diciamo che l'utente può pubblicare una proposta del fornitore prima dell'inizio della negoziazione. Quindi, in diversi punti nel tempo attraverso il processo di negoziazione, l'utente può pubblicare i dati della proposta. La proposta contiene un budget, obiettivi di vendita e molti altri articoli. Quando una proposta viene snapshot, tutte le entità collegate devono essere snapshot. Infine, dopo la negoziazione, viene firmato un contratto. A questo punto, è necessario creare un'istantanea completa del contratto. Non tutte le entità del contratto sono presenti nella proposta: ci sono molte entità sovrapposte, ma ci sono entità uniche allegate a proposta e contratto.

Dobbiamo tenere disponibili entrambe queste versioni pubblicate e le ultime versioni attive. Le versioni pubblicate sono rese disponibili su un sito Web a cui si fa riferimento sia dai fornitori, sia dal team di gestione. Non tutte le versioni pubblicate sono rese disponibili sul sito Web, ma l'ultima proposta pubblicata e l'ultimo contratto pubblicato sono sempre disponibili nel sito Web. Questo sito Web deve anche essere popolato dallo stesso database.

Inoltre, un utente finanziario può decidere di istantaggiare solo il budget da solo e un gestore delle vendite può keaggiare gli obiettivi di vendita. Quindi, le istantanee sono disponibili a più granularità.

Abbiamo anche l'obbligo di tracciare le versioni dei dati anagrafici. È un requisito aziendale tracciare tutte le modifiche alle colonne di dati principali nel tempo. Ad esempio, abbiamo informazioni sulla regione associate agli obiettivi di vendita. Il nome della regione può cambiare e vogliamo tracciare queste modifiche. Supponiamo che al momento della proposta, il nome della regione è R1 e viene creata un'istantanea. Quindi, il nome della regione cambia in R2 e quindi vengono create altre istantanee. Vogliamo in grado di collegare gli obiettivi di vendita al nome della regione corretto in quei punti nel tempo, non necessariamente all'ultimo nome della regione.

Abbiamo una certa flessibilità nella modellazione in quanto abbiamo sia una transazione che un data warehouse DB e possiamo decidere di archiviare alcune di queste informazioni nella transazione DB o nel data warehouse DB.

Ecco il nostro design. Abbiamo una tabella di pubblicazione che acquisisce informazioni di base sui dati pubblicati: che hanno pubblicato e la data, il motivo e il tipo di oggetto pubblicato (proposta o budget o obiettivi di vendita).

Archiviamo le istantanee nella stessa tabella dei dati originali. Quindi, le istantanee delle proposte verrebbero conservate con proposte dal vivo nella tabella delle proposte. Abbiamo una colonna chiamata ID pubblicazione in ogni tabella che deve essere pubblicata. Questa colonna è un FK alla tabella di pubblicazione. Se l'ID pubblicazione è nullo, quel record è la versione attiva.

Mi sono reso conto che il post è molto lungo. Quindi, piuttosto che elencare i dettagli dello scenario, ho pensato di riassumere rapidamente le considerazioni di progettazione in una mappa mentale.

Ora ci sono 2 soluzioni a cui ci stiamo appoggiando: entrambi memorizzerebbero un'istantanea di tutti i dati che siano cambiati o meno. Mantenere solo il delta mantenendo intatti le strutture della tabella richiederebbe una procedura memorizzata molto complessa che deve essere eseguita su ogni inserto/aggiornamento di uno qualsiasi dell'oggetto snapshot. Non voglio percorrere questa strada in quanto ciò richiederebbe più tempo e i volumi non sono comunque così enormi.

Soluzione 1: ogni volta, viene pubblicato un oggetto (come proposta o budget), popolare un albero XML e persistere nel database. Solo l'ultima versione deve essere disponibile nel sito Web e raramente sono necessarie vecchie versioni. Detto questo, mi imbatterei in un grosso problema delle prestazioni a causa dell'utilizzo di XML? Usiamo SQL Server. I volumi di dati non sono così enormi.

Soluzione 2: tutte le tabelle delle transazioni avrebbero un ID di pubblicazione e i dati di riferimento avrebbero le date di inizio e fine. Ogni volta che viene pubblicato un oggetto, faremmo una copia di tutti i record di transazioni e inseriamo l'ID pubblicazione lì e copriremmo tutti i record di dati di riferimento e inseriamo una data di istantanea come data di fine. Ciò ci consentirebbe di avere un versioning normale per i dati di riferimento al di fuori del processo di pubblicazione.

Avrei bisogno di opinioni dalle menti esperte qui per quanto riguarda gli svantaggi di questi 2 approcci e se esiste un altro scenario migliore.

Answer 1

Il mio approccio sarebbe quello di optare per la soluzione 2. Prendere le tue considerazioni di progettazione in ordine:

1. Avrei archiviato una copia di tutto nell'istantanea. Se memorizzi solo la modifica, ti concedi il problema dei dettagli di istantanee del processo per ottenere l'istantanea desiderata dalle modifiche. Inizialmente questo non è un problema, ma come schemi, programmi e processi cambiano, dovrai mantenere i dettagli su come ritirare l'istantanea desiderata da un processo che si è cambiato. Fattibile, ma potenzialmente fragile.

2. Vorrei scegliere un'opzione non menzionata nel tuo diagramma, sebbene disegnato nella tua descrizione della soluzione 2. Questo utilizza uno schema molto simile a quello della transazione DB, ma esteso per includere le informazioni specifiche per le istantanee. Si menziona l'ID di pubblicazione come chiave estera e le date per i dati di riferimento. Potresti scoprire che hai bisogno di ulteriori informazioni come date, relative ai dati delle transazioni.

3. Lo stesso schema non lo farà: hai sottolineato (ID pubblicazione) che lo stesso schema non è adeguato. Nulla in ciò che pubblichi suggerisce che devi adottare uno schema diverso ottimizzato per la lettura. Anche se ciò si rivela richiesto, è qualcosa che può essere incorporato in una fase successiva, con lo schema esteso corrente e esteso come punto di partenza. Non ho molta esperienza con gli alberi XML, ma chiederei "perché introdurre un'altra tecnologia quando hai alternative che possono utilizzare la tua infrastruttura esistente?" Qualsiasi vantaggio che percepisci da questo approccio dovrebbe essere molto significativo per il warrent a buttare via il vantaggio della leva della tua architettura esistente. Considerazioni simili si applicano a un DB denormalizzato. Perché andare lì fino a quando non c'è bisogno di dimostrare?

4. Ancora una volta adotterei l'approccio del monitoraggio delle versioni e delle istantanee. Fornisci un vantaggio primario di questo approccio nella tua soluzione 2. Aggiungerei la snapshot dei dati di riferimento come parte del processo di snapshotting, piuttosto che il processo di versioning. (Cioè quando viene presa un'istantanea, assicurarsi che le tabelle di riferimento appropriate facciano parte dell'istantanea). Dalla tua descrizione sembra che tu abbia due requisiti diversi che utilizzano gli stessi dati: la snapshot e la versione. Sembra che ci sia poca dipendenza tra loro, e quindi dovresti mantenerli il più indipendenti possibile: mancanza di accoppiamento.

5. Si menziona potenzialmente l'utilizzo del data warehouse come archiviazione, sebbene non specificamente menzionato nelle soluzioni. Se i tuoi volumi sono, come suggerisci, basso, avrei pensato che un database separato fosse adeguato. Dagli l'impressione che i volumi di dati e utenti per le istantanee siano bassi, quindi non sembrerebbe essere un caso prima facie per l'utilizzo del data warehouse. Allo stesso tempo, il magazzino ha alcuni meccanismi per archiviare esattamente questo tipo di dati storici, da utilizzare per la lettura e l'analisi.

Mi dispiace di non aver risposto direttamente alle tue domande qui, ma spero che questo fornisca alcuni suggerimenti e un'altra visione della tua situazione dichiarata.