Newsgroup: it.comp.lang.visual-basic
Titolo: Qualche riflessione sulle date...

Salve,
Ho letto vari post sulla gestione delle date,
argomento che sembra incontrare molti problemi in VB.
Il perche' della cosa e' certamente da attribuirsi ai sistemi DB, su
questo non v'e' dubbio alcuno.
Molto presto, temo, anche io avro' a che fare con questo argomento,
sempre per via di una base di dati.
Sono ben lontano dal poter risolvere un problema di cui
non mi sono mai veramente interessato, ma pensavo che
forse potrebbe essere utile - per risolvere il problema -
questa tecnica che sto per descrivere.
Si crea una tabella date cosě formata:
1) ID_DATA( intero )
2) GIORNO( intero )
3) MESE( intero )
4) ANNO( intero )
Poi li' dove serve si usa solo ID_DATA.
Che ne pensate?
Potrebbe risolvere il problema?
TIA
Andrea


Non è male, ma hai sempre una tabella da mettere in mezzo tutte le volte.
Se devi visualizzare devi sempre fare una join.
Io, dopo aver incontrato vari, seri, problemi, ho cominciato a scriverle in
campi testo di 8 caratteri yyyyMMdd
L'unica palla è che bisogna sempre formattarla quando la leggi, e
deformattarla quando la scrivi.

 deformattarla quando la scrivi.
Ma immagino che tu abbia una funzione per questa cosa...
Ciao
Andrea

 Potrebbe risolvere il problema?
Non e' gestibile
Vedo due possibili approcci:
a) memorizzi ogni data univoca una sola volta (il 1 Marzo 2003 esistera' in
un unico record, con il suo ID_DATA); questo certamente porta ad una
compattazione della tabella, peccato che in questo modo innumerevoli altri
record di altre tabelle faranno riferimento ad un unico ID_DATA; se cambi
data ad una informazione quindi rischi di influenzare anche altri (che certo
non e' corretto) oppure devi fare una procedura che vada a sostituire il tuo
ID_DATA con un altro che rappresenta la nuova data da usare (con una SELECT
e un eventuale INSERT se la data in questione non e' mai stata memorizzata)
b) ogni volta che un record usa una data, la inserisci con un nuovo ID nella
tabella, che esista gia' o meno; questo certamente ti risolve il problema di
puntare a date di altri record, ma in compenso fa esplodere esponenzialmente
i record nella tabella delle date
Nota poi che, in entrambi casi, le consultazioni per data diventano
terribilmente complesse; fai una query su un paio di date ed ecco che devi
fare una doppia join carpiata con alias e 2 triplette di 'AND', oppure una
query per sapere i record compresi tra 01/010/2003 e 12/01/2003 e ti tocca
una subquery con IN per recuperare i blocchi di ID corrispondenti...
I campi data in se non sono un problema, basta stare attenti alle solite
cose... eventualmente ci sono alternative piu' semplici; nei nostri
prodotti, per esempio, usiamo il formato yyyymmdd memorizzato in campi
numerici a 32bit, cosa che come altre ha vantaggi e svantaggi:
svantaggi per non poter usare le funzioni data per fornite dal DB
direttamente in statement SQL, vantaggi per il fatto che il formato e le
modalita' di accesso sono senz'altro uniformi per tutti i motori DB, vecchi
o recenti, le prestazioni sono buone e la maggior parte delle comparazioni
possono essere fatte con i normali operatori = > <
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 Che ne pensate?
Penso che dimenticherò i campi Date/Time e archivierò sempre le date come
stringhe di testo nella forma "AAAAMMGG" e le ore nella forma "HHMMSS".
Quelle poche volte che dovrò applicare funzioni particolari (DateDiff, per
esempio) mi farò un po' il culo, ma non mi pentirò... Unica sintassi, Order
By garantito, Where senza problemi, etc.


Si ma è da applicare... :-(..... e tutte le volte :-(((((((

 By garantito, Where senza problemi, etc.
Lo stavo per dire io....
C'č il problema dei calcoli che non puoi piů fare in maniera cosě "diretta",
perň orderby garantito, where sicura e poche pippe da un database all'altro.

 sui database e la ridondanza dei dati, comunque sono solo opinioni.
Questa, IMHO, non è ridondanza, ma ... necessità. Cosa accadrebbe se si
ristampasse un documento e nel frattempo la descrizione dell'articolo è
cambiata? Sarebbe diverso dall'originale, bruttissima cosa! ;-)

 cambiata? Sarebbe diverso dall'originale, bruttissima cosa! ;-)
E se fosse stata eliminata?
E' uno dei motivi.
Si potrebbe anche creare un sistema per ovviare, ma perchè rompersi la testa
quando basta ridondare un po' coi dati? :-)

 quando basta ridondare un po' coi dati? :-)
Insisto e preciso: La ridondanza "inutile" (solo così può essere definita
tale) non piace nemmeno a me, la "ripetizione utile e/o necessaria" non è
assolutamente criticabile.
Aggiungo anche, nell'esempio che facevo: Non è escluso (per alcuni miei
clienti è quasi la prassi) che la descrizione dell'articolo venga solo
proposta dalla sua anagrafica in una riga di documento. Questa stessa riga
deve poter essere modificata (anche nella descrizione) per le
"personalizzazioni" del caso, per esempio, per accodare altre indicazioni.
Per me il campo descrizione di una riga documento è sì proposto
dall'articolo (se l'articolo è citato e non è una riga puramente
descrittiva), ma è disponibile per ogni intervento, esattamente come la qtà
o il prezzo. Che conta, alla fine, è il codice dell'articolo per effettuarne
(in quel momento o dopo) gli aggiornamenti relativi (qtà e valori)

 (in quel momento o dopo) gli aggiornamenti relativi (qtà e valori)
Da noi è uguale identico, il codice del prodotto serve per fare i movimenti
di carico/scarico dal magazzino e operazioni analoghe, per il prezzo, etc...
Ma alla fine la descrizione non è così pesantemente legata all'anagrafica.

 Poi li' dove serve si usa solo ID_DATA.
Può essere utile *SOLO* nel caso in cui tu debba avere delle scelte
obbligatorie sulle date, altrimenti è assolutamente dannosa.
Un join in più rende molto più complessa la lettura dell'SQL, specie se già
contiene altri 3 o quattro join.
Figurati se poi ogni tabella "joinata" si deve a sua volta "joinare" con
quella delle date e magari per più di una data a tabella...
Beh, auguri!
Inoltre sarei curioso di sapere come gestiresti i campi disgiunti anno,
mese, giorno.
Se devi fare differenza tra date?
Anche solo per visualizzarle devi fare i salti mortali o unirle comunque in
un DateValue e poi formattarle.
E se hai bisogno anche delle ore?
Mi sembra proprio una pessima idea.
Consiglio: usa campi DateTime, usa il formato iso #yyyy/mm/dd# in SQL e
leggili/scrivili come un qualsiasi valore da recordset, e risolvi tutti i
tuoi problemi con 0 (zero!) sforzi.
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net