Newsgroup: it.comp.lang.visual-basic
Titolo: Ma allora è tutto un cavolo!

Ciao a tutti.
Ho appena fatto una prova:
ho preso due database 'perfettamente identici' da 22400 record fatti con
Access, ed ad uno dei due ho messo degli indici ed un chiave primaria
(secondo le mie esigenze).
Beh il guadagno è stato di 0,3 sec, rispetto alla seguente query:
    select * from tabella where altezza=174
Ma allora a che cacchio servono gli indici? Così facendo il risparmio di
tempo diventa apprezzabile (qualche secondo non di più) solo per database
con milioni di record?
Ciao a tutti e spero che capiate il mio sconforto.

WebPC wrote:

Beh, l'indice funziona....quando lo usi. Prima di tutto, bisogna capire gli
0.3 sec. rispetto a quanto in totale. Se rispetto a 1 o 2 sec., l'incremento
non e' malvagio, se rispetto a 10, 20 sec. c'e' poca differenza...Inoltre,
bisogna sapere se hai messo un indice effettivamente sul campo ALTEZZA, o su
un altro campo chiave.
Bye by Massimo 8-]

 wrote in message
96rch5$3ro$1...@nreadA.inwind.it...

Ricordati che stiamo parlando di MS Access non di ORACLE!
Access non è ottimizzato con i comandi SQL, bhe, MS dice di si, ma come
vedi.. . .
Comunque prova ad aprire quella stessa tabella in formato Table in un
recordset,
e prova a richiamare il metodo seek per fare la tua ricerca del record con
altezza=174; Li si che apprezzerai la straordinaria velocità fornita dagli
indici.
La ricerca sarà praticamente istantanea.
--
 /\/\/\/\/\/\/\/\/\/
| Partecipa alla stesura di progetti VB sviluppati in team,
| informati sul Sito Comune sezione Leonardo.
| Io partecipo al progetto Data Rapto, alleati con noi.
 \/\/\/\/\/\/\/\/\/\
Ciao
Ettore Maronese, il Mes
http://www.maronese.com/mes
Sito Comune di questo NG
http://www.murialdo.it/it_lang_vb

 tempo diventa apprezzabile (qualche secondo non di piů) solo per database


Ma allora a che cacchio servono gli indici? Così facendo il risparmio di
]zac[
Gli indice nei database mdb, usando ADO, DAO, ecc. sono praticamente
inutili.
Bisognerebbe utilizzare quei motori di db (io conosco solo informi sotto
linux) dove non esiste il recordset ma solo il record corrente, e ogni
operazione e' fatta sugli indici.
Sono molto grezzi ma sono di una potenza notevole, i milioni di record sono
il loro pane quotidiano.
Salve
                Dbg

 inutili.
AAAAAAAAAAAAAAAAAAAAAAARGH !!!!
in dao, con uno stupido seek posso piazzarmi al centro di una tabella di
alcuni mln di schede in una frazione di secondo, e scorrere quelle prima e
quelle dopo. non c'e' il limite di una query selettiva, hai tutti i dati
li'.
sembra niente. ma supponi una query
    where filename = "pippo.mp3"
gia' e' piu' lenta. se poi la fai con like ci metti parecchio di piu'.
non basta. con un seek ti posizioni
    piippo.mp3 'refuso
    pippo_.mp3
-->    pippo.mp3
ecc. ecc.
cioe' vedi sopra e sotto. e un casino di errori, ti assicuro saltano fuori.
con sql non e' cosi' immediato. devi avere molto intuito e molta fortuna. e,
cosa non secondaria, controllare molto di piu' il dataentry, quindi
appesantire il prg, ecc.
nb. non dico che siano meglio. dico che sono complementari all'uso di sql.
che poi siano tecnicamente incasinati da usare specie in rete locale o
remota, altra faccenda. ma io sto patendo non poco a reimpostare proprio il
modo di affrontare le tabelle, senza.
ciao, a.



Domandina: se la seek e' fatta su un campo non chiave, poi come itero se ci
sono piu' valori?
Bye by Massimo 8-]
P.S. Non avendo mai usato la seek...


La seek si può fare soltanto su campi indicizzati.
Comunque, se non l'hai mai usata, fatti un piacere, non cominciare proprio!
E' un residuo del passato (leggi db3 e Clipper), e va contro la filosofia
dei db relazionali. Tanto per dirne una, Sql server e Oracle non la
supportano, ed inoltre aumenta notevolmente il traffico di rete. Ciò
significa che se vorrai fare l'upsize a Sql server, dovrai riscrivere tutto
il codice che usa le seek. In certi casi è effettivamente molto comoda, ma
non esiste un caso in cui non si possa risolvere, pensandoci un po' su, con
delle select ben congegnate. Inoltre una select con una condizione su un
campo indicizzato va alla stessa velocità di una seek, per il semplice
motivo che che Access usa l'indice per costruire il recordset. Il test che
hai fatto con 22.400 record è fuorviante, perchè con i computer moderni
scandire in modo sequenziale 3/400 K è un'operazione quasi istantanea.
Quindi è prevedibile che le differenze siano piccole. Lavora su un numero
maggiore di record, o su query con join sui campi indicizzati, e comincerai
ad apprezzare le differenze.
Io personalmente, mi sono imposto da un paio d'anni di non usarla più, e
dopo un po' di disorientamento iniziale non la rimpiango, e guardo
serenamente alle nuove tecnologie, senza temere di dover riscrivere il mio
codice...
Ciao
Alfonso Moscato

AAAAAAAAAAAAAAAAAAAAAAARGH !!!!
Tranquilizzati, Intendevo nelle query sql.
Il seek e' una cosa che mi piace, ma ha un po' di limiti.
Per gestire milioni di record si puo' solo utilizzare le ricerche via indice
e niente recordset.
Ho un progetto in mente, ma e' troppo grosso, ci vorrebbe l'aiuto di persone
con conoscenze varie.
Un db con accesso solo a indici posto sul server, e un client che dice al
server che istruzioni eseguire (non solo sul db, anche di codice) e
visualizza solo i risultati.
Salve
                Dbg

dei db relazionali.
Qui ti sbagli.
Ho alcuni database che contengono milioni e milioni di record (roba di un
supermercato), se non ci fosse un db a indici le prestazioni calerebbero in
maniera mostruosa.
Per avere prestazioni paragonabili ci vorrebbe sql server con 1Gb di ram e
un Vax come server.
Salve
            Dbg


Mai detto che non ci vogliono indici. Anzi! Quello che secondo me č
sbagliato č che li si usi esplicitamente. anche perchč i db relazionali di
un certo livello ne usano diversi tipi, a seconda del tipo di operazioni che
si fanno sui dati, li possono cambiare, crearne di nuovi temporanei, e cosě
via. Se tu li usi esplicitamente li costringi ad utlizzare quelli, mentre
invece in certi casi il query optimizer potrbbe valutare che una scansione
sequenziale (si fa per dire) costa meno. Quindi ribadisco: ad ognuno il suo
lavoro; i db ottimizzano gli accessi ai dati, gli esseri umani progettano la
basi dati con ESTREMA attenzione (i miglioramenti che si possono ottenere
con una buona progettazione valgono piů di 10 indici), e magari danno una
controllata alle decisioni prese dall'optimizer (č pur sempre un programma,
gli esseri umani sono meglio).
Comunque se usi la seek sei condannato a lavorare con Access tutta la vita.
Anzi ti dirň di piů: nella prima versione di Ado la seek non c'era, e la
hanno poi inserita in un secondo momento perchč c'č troppa gente che la usa.
Quindi č ipotizzabile che abbia i giorni contati...
Ciao
Alfonso Moscato

Quindi è ipotizzabile che abbia i giorni contati...
Non contarci, c'e' informix server e altri simili, pero' vanno per la
maggiore nel mondo unix.
Salve
                Dbg


[...]
Da quello che scrivi capisco che non ho capito.
Io pensavo che ti riferissi a db relazionali. questi che citi non li conosco
(Ma Informix non era relazionale anche lui ?). quindi mi ritiro in buon
ordine. Mi chiedo solo, ma una query con 20 tabelle, come si fa, tutto a
mano, a la Clipper (spero proprio di no)?
Ciao
Alfonso Moscato

 Alfonso Moscato
ciao, a.

 Quindi è ipotizzabile che abbia i giorni contati...
gia'. come il dos...
ms da' vita a mostri che poi e' costretta a mantenere tutta la vita...
se ne sono resi conto, e cercano di regalare msde. ma ci vorra' un po'
perche' ci riescano. e dovranno munirlo di qualcosa di decoroso senza
costringere bravi programmatori a fargli un'interfaccia.
filosofie...

 vorrei assumerti a modello... :)
Guarda, dei sonori vaffa... li ho mandati anche io, salvo poi ritrovarmi a
pensare dopo aver cambiato che il nuovo era molto meglio. Io mi sto facendo
vecchiarello (ho 38 anni, nell'informatica sono tanti, penso  che tu possa
capirmi, con tutti 'sti sbarbatelli geni dell'informatica :-) ), il cervello
è sempre meno elastico, il cambiamento costa sempre di più, alla fine
bisogna scegliere se fermarsi o no. Io ho deciso di abbandonarmi al
cambiamento: ogni volta che esce qualcosa di nuova me la studio con avidità,
e ti dirò che alla fine mi ci diverto pure. Ti faccio un esempio: fino a
settembre scorso non avevo mai lavorato in Vb; conoscevo benissimo Access,
Visual C++, Powerbuilder ecc., ma non Vb. E più passava il tempo e più mi
sentivo tagliato fuori. Così quando la mia vecchia azienda mi ha
commissionato un lavoro in Powerbuilder, gli ho proposto di farlo in Vb.
All'inizio mi sono maledetto per questa gloriosa idea, perchè un lavoro di
un mese me ne è costati quasi 4, ma adesso ne sono ben contento. In più
l'esperienza conterà pure qualcosa, no? Se uno è esperto ad imparare le cose
nuove ci mette un decimo.
Cmq se vuoi assumermi a modello, ne possiamo parlare, se lo stipendio è
buono... Però sfilate di intimo non ne faccio, ho il culo grosso! :-)
Ciao
Alfonso

 buono... Però sfilate di intimo non ne faccio, ho il culo grosso! :-)
lo stipendio e' pessimo. per il resto, never mind, dopo bonolis non ci sono
piu' muri da sfondare :)
ciao, a.

 piu' muri da sfondare :)
Per lo stipendio di Bonolis sfilo anche nudo.
Ciao
Alfonso

mano, a la Clipper (spero proprio di no)?
Si!, tutte con find a manima, ma e' meno difficile di quello che sembra,
invece che fare una query fai un loop.
Pero' la ditta per cui lavoro ha due clienti con db da 1Gb e con alcune
tabelle da 1,5 milioni di record, e cavoletti il programma su cui lavoro (e'
un client (stupido) server (server linux)) non fa' una piega.
Cmq riconosco che farsi le librerie (sono proprietarie e compilate)
necessarie e' un lavoro spaventoso.
Salve
            Dbg


[...]

Allora ho capito, forse ti riferisci alle mitiche c-isam, le conosco. Perň


 Per lo stipendio di Bonolis sfilo anche nudo.
ok. appena (*) ho occasione gliene parlero'.
ciao, a.
(*) leggasi "se mai ne"


Al limite anche per la metà.
ciao
Alfonso

 palle! :-)
spero che neanche qualcuno di ms segua il ng. se leggono quanto sopra, la
prossima piattaforma ("interstellar" o simili, suppongo) te la mettono con
un sovrapprezzo per il divertimento assicurato...