Newsgroup: it.comp.lang.visual-basic
Titolo: Gestire le variazioni: e la base dati??

Ciao a tutti,
ho questo problema che, per scarsa esperienza, non so come gestire.
Devo scrivere una nuova applicazione, dove il cliente mi chiede di gestire
ogni variazione ai dati. Ad es. se nella tabella "dipendenti" una voce è
la residenza angrafica, occorre gestire la variazione così:
- l'utente effettua la modifica
- viene registrato nella "base dati" interna al programma la variazione
con la data attuale
- dopodichè, tutti i report successivi riportano l'indirizzo vecchio fino
alla data attuale, e poi quello nuovo dalla data attuale in poi...
(spero di essermi spiegato)
In particolare, mi chiedo come strutturare la base dati: un qualsiasi DB
relazioale, manterrebbe il link solo all'ultima chiave.
Idee? Suggerimenti?
Grazie in anticipo...
-- 
-----------------------------------
"A strange game. The only winning move is not to play"
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Idee? Suggerimenti?
io di solito divido le cose :
le stampe le creo non con gli ID ma con i dati veri e propri di stampa, la
stampa poi la lego con degli id ma non sono importanti, esempio, creo una
tabella "fatture" che lega clienti, articoli date prezzi ecc... e IN PIU' ha
un IdStampa che lega quella fattura alla sua stampa.
quando creo la stampa non passo ID ma passo il campo.
esempio di stampa di una fattura :
IdStampa = 1
Intestazione = "bla bkla nbla"
Cliente = "Cartastracci SPA" ' e non magari idCli = 1
Articolo = "Rotolone 2piazze per chiappe possenti" ' e non magari IdArt = 2
ecc ecc...
in questo modo memorizzo la stampa in modo che SEMPRE sia richiamabile cio'
che effettivamente e' stato stampato.
Ovviamente non e' sempre applicabile questa formula, ad esempio se il
cliente volesse ricreare la stampa hai 2 possibilita' :
1) creare un nuovo record di stampa o
2) modificare e ricreare il record di stampa modficicato perdendo la stampa
precedentemente effettuata.
justmy2c
-- 
-Gigio2k-

 le stampe le creo non con gli ID ma con i dati veri e propri di stampa,
Ok, grazie per la risposta.
Quindi, se ho capito quello che intendi, tu tieni sempre una tabella per
ogni stampa dove hai tutta la "storia" dei dati, con le relative
variazioni? Quindi, essendo quella tabella di stampa "svincolata" dai dati
veri e propri, tu hai la possibilità di mantenere i dati che vuoi. Giusto?
..e se devi aggiungere un nuovo tipo di report (di stampa)?
Come fai a recuperare i dati?
Grazie ancora.


 un IdStampa che lega quella fattura alla sua stampa.
Questo sistema storicizza i valori dei campi al momento della stampa,
ma ha come difetto di aumentare la dimensione del DB, ha senso farlo
per dati per cui effettivamente ha importanza mantenere il valore
originale (ad esempio sulle fatture).
Si potrebbe anche gestire una tabella che mantiene lo storico, con la
data di modifica come chiave aggiuntiva (e ovviamente gestie sempre e
solo l'insert e mai l'update) e far si che le stampe vadano a prendere
i dati da quella tabella utilizzando come parametro la data in cui è
stata fatta la stampa (oltre all'id cliente per es.)per la ricerca
delle informazioni nella tabella.
Ma non ti consiglio di farlo, ti complicheresti la vita ad oltranza.
Piero

 Come fai a recuperare i dati?
ecco il problema, devi scegliere tutto all'inizio, ad esempio stampavo
"normalmente", con i vari indici le colonne dei prezzi articoli per cliente,
poi l'utente mi ha chiesto di tenere lo storico e quindi ho dovuto
rimodificare la stampa passando i campi veri e propri e memorizzando il
risultato (cosa che con gli indici occupano poco spazio, ma con i testi...
uff...)
-- 
-Gigio2k-