Newsgroup: it.comp.software.database
Titolo: Tabelle "temporali"

Devo strutturare dei dati in delle tabelle che dovranno mantenere lo
storico delle versioni, per dover risalire ai valori dei dati nel tempo.
ES: TabellaAnagrafica: Cognome, Nome, Indirizzo
Rossi, Mario, Via Verdi 50
Se la persona cambia indirizzo oggi dovr� avere
Rossi, Mario, Via Verdi 50, 19-04-2010
Rossi, Mario, Via Rossi 20
Io pensavo di aggiungere alle tabelle 3 campi:
- ValidoDal DATE (automatico, la data di inserimento)
- ValidoAl DATE (Ad ogni insert setto a NOW tutti quelli precedentemente
validi)
- ValidoSN BOOLEAN (mi dice se il record � quello valido o meno, per
semplificare le select "normali").
Mi domandavo se un approccio del genere possa essere corretto, oppure sia
meglio spostare i dati in un'altra tabella specchio(ma qui le eventuali
stampe dei dati precedenti dovrebbero cambiare nome di tabella, e dovrei
replicare le modifiche di struttura di tabella).
Ogni recupero dati "storicizzati" sarebbe del tipo:
Select * From TabellaAnagrafica Where ValidoDa<= DataRif AND
Coalesce(ValidoAl,31-12-9999) =>DataRif
Quella per i dati attuali:
Select * From TabellaAnagrafica Where ValidoSN=True
Poi i campi saranno Date_Time pi� che Date semplici, probabilmente.
Grazie

On 19 Apr, 15:13, "Andrea [Work]"

Ciao andrea,
io ho lavorato su di un db che trattava dati "time oriented", quindi
con tabelle strutturate più o meno come dici tu. Non ho riscontrato
nessun problema, quindi per le mie esperienze  immagino che la
struttura sia impostata correttamente.
C'è questo libro che dovrebbe trattare poprio situazioni come quelle
che devi affrontare. Non so se utile e, soprattutto, se si ha tempo di
leggerlo....comunque lo posto:
 
http://www.cs.arizona.edu/people/rts/tdbbook.pdf
ciao
------------------------------------------------------------
michele
http://micheledemeo.blogspot.com/

 Rossi, Mario, Via Rossi 20
no so se ho fatto una "porcata", ma per una cosa del genere io
ho fatto una tabella "appoggio" del tipo
tbl_id integer not null references tabella(id),
datavar date not null default now(),
descr varchar(50) not null,
text_val text,
date_val date,
int_val integer,
num_val numeric(10,2),
...
e ad ogni variazione sulla table carico i dati, a seconda del tipo, nella
tabella appoggio ... ad es, se il 4/2/2010 cambia l'indirizzo di
2, Mario Rossi, via Roma 22
nella tabella appoggio avremo
tbl_id 2
datavar 2010-2-4
descr indirizzo
text_val via Roma 22
e nella table principale
2, Mario Rossi, via Verdi 22
e poi ti fai una view o una stored procedure che prende in input la
data della query per riportarti la situazione a quella data ...
ripeto, non so se ho fatto una porcata, ma funziona e serve per i
miei scopi ...
saluti
-- 
Never try to teach a pig to sing.
It wastes your time and annoys the pig.

  
http://www.cs.arizona.edu/people/rts/tdbbook.pdf
Grazie ci do' un occhio.

 miei scopi ...
Il problema è che io avrei 7/8 tabelle di questa tipologia, e avere i dati
su tabelle differenti comporterebbe switchare il datasource ogni volta, ma
soprattuto replicare tutte le variazioni di struttura alle tabelle con dati
storicizzati.
Se indicizzo il campo che mi dice se un dato è valido o meno, le query
standard dovrebbero essere comunque rapidissime, i dati reali attivi
saranno 4/5 mila record massimi. Molte tabelle ne avranno meno, o saranno
tabelle di 4/5 campi solamente.