Newsgroup: it.comp.software.database
Titolo: Storicizzazione/revisione dei dati

Caso d'uso:
Azienda che ha dei clienti che effettuano degli ordini per i quali 
devono essere emesse delle fatture.
Nel corso del tempo i dati relativi ai clienti possono variare, ma 
l'azienda vuole mantenere tutto lo storico dei dati.
Soluzione 1.
Ogni fattura ha all'interno anche una replica dei dati del cliente nel 
momento in cui è stata inviata => aumento di spazio
Soluzione 2.
Ogni cliente implementa un meccanismo di revisione senza numero di 
revisione ma con una data di inizio validità.
Esempio:
la tabella clienti sarà composta dai dati
(idCliente, dataInizioValidita, statoValidazione, RagioneSociale, 
PartitaIVA, ...)
ove la chiave è la coppia (idCliente, dataInizioValidita).
Ogni qualvolta devo modificare i dati di fatturazione del cliente, creo 
una nuova revisione dello stesso.
Nel momento in cui approvo/valido questa revisione, per tutti gli 
oggetti che fanno riferimento a quel cliente da quella data in poi 
prenderanno il nuovo record.
Ogni record collegato dovrà quindi avere un suo campo data che contiene 
la data in cui è stato "validato" (e quindi la data di riferimento per 
sapere di quale revisione sto parlando) - in certi casi potrebbe anche 
essere il timestamp di creazione.
Soluzione 3.
Creo record copie del cliente, ogni fattura e' collegata alla copia di 
riferimento e dovrà essere implementato un meccanismo di collegamento 
tra le copie di stessi clienti.
A me sta interessando la soluzione 2, magari da esplodere meglio...
Il software gestionale dell'azienda in un anno ha raggiunto i 15 gb e 
non volevo utilizzare la soluzione 1.
D'altro canto la soluzione 2 è la piu' difficile da implentare e 
richiede dei join piu' complessi... magari si puo' pensare di creare una 
vista per ogni collegamento per poter cosi' ridurre i tempi computazionali.

La soluzione 2 e la 3 sono sostanzialmente la stessa cosa. Crei una 
"super-entità" cliente che è in relazione uno-molti con i suoi dati 
(indirizzo, ragione sociale, ecc).
Ogni volta che interroghi il DB dovrai avere due punti di join: l'id 
azienda (classica relazione chiave primaria - chiave esterna) e la data.
Per ottimizzare i tempi direi di creare dei buoni indici sui campi di 
validità della tabella "dati_cliente".
Certo questo non è un bel lavoro da fare su un sistema già pieno di 
dati... auguri!
Alex.

 dati... auguri!
Per fortuna dobbiamo partire da 0 in questa analisi... poi il porting sarà 
divertente..... 

 A me sta interessando la soluzione 2, magari da esplodere meglio...
Ti avviso che una temporal table è tutta un'altra bestia rispetto ad
una tabella classica: ogni query deve essere ad-hoc, ed una svista
di una query scritta nel modo "classico" causa la restituzione di
dati errati; questa è application-managed data integrity.
Oltre a questo, rimangono da scegliere vari simpatici dettagli, tipo
quale granularità usare, se userai gli intervalli close-open o
close-close, il livello di supporto nel dbms (ossia quanto farà il
dbms e quanto scriverete a mano), e poi userete un modello
chronons o continuum? Le conoscete, vero, tutte queste cose?
Scommetto che la soluzione 1 non ti fa più tanto schifo :-)
bye

 Scommetto che la soluzione 1 non ti fa più tanto schifo :-)
Anche io utilizzo questa nel sw dove sto lavorando.
Diciamo che è molto comoda e flessibile, ad esempio ad un cliente si
assegna un codice pagamento predefinito, e per quel documento è diverso, si
cambia nel documento e stop.