Newsgroup: it.comp.appl.access
Titolo: Memorizzazione date in formato diverso dal Date/Time

Salve a tutti.
Come precedentemente discusso con Alex Baraldi riguardo al fatto di 
contenere piů informazioni in un solo Campo per ragioni di spazio o di 
suddividerle in piů campi per velocizzare le ricerche (ma aumentando le 
dimensioni del database), volevo la Vostra opinione su questo:
Attualmente, nella tabella "Preventivi salvati" del mio db, vi č il campo 
Dataprev in formato Data/ora che contiene la data del preventivo. Tale campo 
occupa "preziosissimi" 8 bytes per record. Inoltre č risaputo che la 
gestione delle date richiede molta attenzione, soprattutto nel loro 
inserimento nelle query di selezione come criterio (difatti se non vengono 
girati il giorno ed il mese, la maggior parte delle volte i risultati sono a 
dir poco sconcertanti). Vi č inoltre spreco di spazio in quanto l'ora non mi 
serve.
Siccome il mio db lavora per anno contabile, l'anno selezionato sarŕ il 
filtro principale, ma diversamente a come tutti possiate pensare, il filtro 
non lo eseguo sulla data bensě sulla chiave primaria, che essendo intero 
lungo contiene es:
2006100253
2006 anno
1 tipo preventivo
00253 num. preventivo
e questo grazie ad una stupidissima funzione che estrae l'anno dall'intero 
lungo. In ogni caso, avendo filtrato la data (es. "WHERE 
year(Dataprev)=2006") sarebbe servita lo stesso una funzione e comunque un 
conseguente calo di prestazioni nella query.
Stavo pensando a scomporre la chiave primaria (4 bytes, intero lungo) cosě:
Anno (2006) Campo Intero, 2 bytes di memoria
Tipo (1) Campo Byte, 1 byte di memoria
Numero(253)Campo Intero, 2 bytes di memoria
Con il risultato di 5 bytes. L'univocitŕ del record verrebbe mantenuta 
istituendo una chiave primaria su campo multiplo (in questo caso, i 3 
campi).
Il campo data/ora verrebbe invece ridotto ad un intero lungo, con il 
passaggio da 8 a 4 bytes, cosě:
Data/Ora    31/12/2005
Intero Lungo    20061231
Con il risultato di essere contenuto in metŕ spazio, di facilitare la 
gestione dei filtri ridotta al semplice paragone tra numeri e non ad una 
cosa troppo vulnerabile da scarsa praticitŕ quale il Date/Time.
Chiaro che poi all'utente la data dovrŕ risultare nel formato corretto.
La conclusione finale sarebbe:
-Risparmio di (4+8)-(2+1+2+4)=3 bytes
-Abolizione di funzioni di supporto per filtrare la tabella in base agli 
anni, ai preventivi e ai tipi.
-Semplicizzazione della gestione dei dati
-Velocitŕ nell'esecuzione delle query filtrate, potendo contare su piů 
indici costruiti su altrettanti campi.
Cosa ne pensate a riguardo?
Michele
joyl...@alice.it

 indici costruiti su altrettanti campi.
Te lo dico io quale sarebbe la conclusione finale:
- 3 MB di database risparmiati ogni 3 milioni di record: simpatico, ma credo 
che con 3 milioni di record i problemi importanti da affrontare sarebbero 
altri, mentre con un numero nettamente inferiore di record la differenza 
di spazio occupato non si sente nemmeno. Non stiamo mica programmando in 
Assembler, dove anche il singolo bit è sacro. Un hd da 200 GB ormai ha prezzi 
irrisori.
- la gestione dei dati ti si complicherebbe da matti, visto che dovresti 
riscrivere (e testare) delle funzioni che sono presenti e ben funzionanti 
da anni nella libreria di Access.
- la velocità delle query non dipende dal numero degli indici utilizzati, 
bensì dalla qualità degli indici stessi.
Ravvediti: sei sempre in tempo a ripensarci.
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype: pbsoftsolution

 
joyl...@alice.it
ALT facciamo chiarezza.
Una data occupa 8 Byte se contiene hh:mm:ss, al contrario se ha solo
yyyy:mm:dd
potrà essere convertita con un Long(4Byte).
Tralasciando i 3Byte risparmiati sui quali ho diversi dubbi, ma non
penso siano l'ago della bilancia, cercavo di capire l'oggettiva
necessità della valutazione, anche perchè volendo estremizzare si
può risparmiare ancora 1Byte usando 3 campi Byte e visto
che siamo negli anni 2000 possiamo semplificare usando solo 2 cifre:
aa+mm+gg=3Byte
;-)
Le query una volta strutturate non servono modifiche sostanziali, nel
caso il campo non
contenga hh:mm:ss basta la conversione in Long del campo Data e non
serve nessuna inversione.... e guarda un pò sono sempre 4Byte....!!!!
CLng(TuoCampoData)
strSQL = "SELECT * FROM T1 WHERE T1.Campo > " &
cstr(CLng(TuoCampoData))
Avendo una DATA puoi un domani, sempre meglio essere lungimiranti,
creare Query con raggruppamenti per Mese in modo veloce senza impazzire
a ricordare l'alchimia meccanica.......
Non saprei cosa dire, nel senso che le esigenze vanno viste un pò a
largo spettro, e
personalmente l'uso di un campo DATA come tale lo trovo sempre utile.
Mi sono fermato all'analisi dell'errore di partenza dal quale hai
basato il tuo ragionamento...!
@Alex

 
joyl...@alice.it
Si ragazzi, forse avete ragione voi.... gli HDD da 200 GB ormai te li tirano 
dietro (devi stare attento quando sei per strada); a 3 milioni di record, se 
la mia attività un giorno vi dovesse arrivare, non sarò più qui a pormi il 
problema...... O sarò ricco sfondato, o sarò morto (tiè).
Adesso che ci penso, questa mia performance mi ricorda i calcoli che fecero 
sulla velocità della slitta di Babbo Natale: se non ricordo male, la 
velocità era talmente elevata da far prendere fuoco la slitta. Ma ragazzi, è 
Babbo Natale!
La mania di dover migliorare qualcosa per forza, anche se non ve n'è 
bisogno, è una cosa che mi perseguita.
Per il bene del NG, mi guarderò da scrivere ancora roba del genere.
Ragazzi, buona notte e grazie delle Vostre opinioni.....
Michele