Newsgroup: it.comp.appl.access
Titolo: ottimizzare query con 14000 record

ho una query che gestisce circa 14000 record composti da 2 campi: DRG e
DIAGNOSI.
ho importato questi dati da un documento che li metteva in ordine di DRG .
questo è un campo testo organizzato con una numerazione particolare che ho
gestito tramite codice.
la numerazione è del tipo
001            'menu principale
002            'menu principale
002.1         'sottomenu di 002
002.11       'sottomenu di 002.1
002.12       'sottomenu di 002.1
002.2         'sottomenu di 002
...
999            'menu principale
ovviamente la ricerca di informazioni all'interno di 14000 record non è
veloce utilizzando query semplici, che inoltre utilizzano anche funzioni da
me create per fare delle suddivisioni nei vari menu e sottomenu che derivano
dalla numerazione DRG.
credo però che essendo la numerazione crescente sia un vantaggio per
analizzare il recordset.
Quello che a me serve è infatti muovermi tra i vari menù che i drg creano ad
esempio:
alla prima visualizzazione ho
001
002
003
...
999
e selezionando 002 avrò
002.1
002.2
e selezionando 002.1 avrò
002.11
002.12
per muovermi nel sottomenù selezionato eseguo delle query che mi ricercano
in TUTTO il file.Ho pensato che sarebbe molto più veloce se la query che
dovrei implementare col vostro aiuto non analizzasse tutti i record ma possa
saltare in avanti o indietroguardando che la parte iniziale del drg(qualcosa
di simile ad un algoritmo di tipo Bubble sort o qualcuno simile) .Un'altra
caratteristica di questa query dovrebbe essere anche quella di fermarsi nel
cercare una volta che il si sia trovato un drg di un sottomenù diverso da
quello selezionato.
Un altro parere:
secondo voi, visto la mole di dati, mi conviene eseguire una sola volta le
procedure di suddivisione dei dati in menu e creare 3 tabelle diverse che
conterranno i tre menu progressivi (che avranno rispettivamente i drg del
tipo XXX ; XXX.X ; XXX.XX)? Penso che già il fatto di non eseguire più volte
la stessa procedura di calcolo possa velocizzare il tutto.
Si consideri che non ho l'esigenza di modificare ulteriormente questi dati
in quanto utilizzo questi dati in sola lettura per poi utilizzarli copiando
il codice drg in altre tabelle di immisione dati.
Vi ringrazio moltissimo per la vostra collaborazione.
[OT]Vi prego di darmi anche un'altro consiglio:
mi rendo conto del fatto che ho scritto molto cercando di essere più preciso
possibile nel spiegarvi il mio problema.Non so se questa può essere una cosa
utile o meno... fatemi sapere ciò che ne pensate anche perchè non vorrei
ammorbarvi con messaggi lunghissimi che poi non risultino utili anche a
tutti gli altri che frequentano il newsgroup.
Personalmente ritengo di aver imparato molto dalle risposte agli altri post
e ritengo che sia notevolmente più facile imparare se le cose sono spiegate
dettagliatamente...in questa logica ho scritto questo messaggio...spero che
siate daccordo con me...altrimenti...vedrò come modificare il mio modo di
scrivere.
grazie a tutti (soprattutto per aver letto fin qua!!!)

 dalla numerazione DRG.
[cut]
Hai creato un indice sul campo DRG?
E' inutile continuare senza questa informazione...
A presto
Michele Amato
--
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
Sulla mia pagina personale
http://utenti.worldonline.it/micheleamato
è possibile trovare del materiale relativo ad Access
scritto da me, sia freeware che shareware
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}


sperando che ti rifersca a questo ti dico come è fatta la mia tabella:
ID              contatore       indicizzato (duplicati non ammessi)   chiave
primaria
DRG          testo              non indicizzato
Diagnosi     testo              non indicizzato
non ho messo drg come chiave per precauzione...il file dove risiedono i
dati, come già detto, era da importare e difficilmente controllabile visto
le dimensioni.
hai qualche consiglio su questo?
ciao e grazie per l'aiuto...

 wrote in message
6ZUo6.93956$Y93.2...@news.infostrada.it...

Ok hai un indice univoco (abbinato alla chiave primaria) peccato che le tue
query abbiano delle where condition di tipo DRG = '123.123'
Perciò io comincerei col un indice non univoco sul campo DRG.
Valuta le differenze di performance, dovrebbero sentirsi già.
E' chiaro che l'ideale sarebbe un indice univoco. Tu però dici "questi dati
mi arrivano dall'esterno e non è detto che sul campo DRG ci sia univocità".
Bene allora perchè non importi questi dati in una tabella tipo DRG_TMP, con
la stessa struttura di DRG, fai i tuoi controlli e quando sai che tutto è
ok, con una bella query di accodamento non travasi tutto in DRG?
Così facendo potresti trasformare l'indice non univoco definito
precedentemente in indice univoco.
Purtroppo gli indici sono sfruttati raramente dagli utenti Access. Ti
consiglio di documentarti a proposito.
Io ho un "grosso" cliente, che usa Access al limite (lo faceva già prima di
diventare mio cliente).
L'mdb più piccolo che ha è da 700MB, fino a 1500Mb (circa 500.000 record,
molto "larghi").
Lui interrogava questi database, con delle condizioni, e sui campi delle
condizioni (che erano sempre gli stessi) NON AVEVA DEFINITO GLI INDICI!!!
E' bastato definire un paio di indici, fra l'altro di consiglio di vedere
Strumenti->Analizza->Prestazioni,
e sono diventato un eroe.
Query che prima impiegavano mezze giornate adesso vanno in meno di 10
minuti.
... ma io non mi sono montato la testa, figurati ;-)
HTH
Michele Amato