Filippo Cerulo ha scritto:
Marco Quarona ha scritto:
At 09.32 04/01/2008, you wrote:
In altre parole, l'aggiunta di criteri di selezione è un motivo di
criticità del DB?
No, a meno che il motore del db (o la il db stesso) siano stati
progettati male. I filtri velocizzano le query, non le rallentano.
Questa è davvero una tesi interessante......
in un dbms semplice e leggero probabilmente no, ma in DBMS ideale sì
(oracle ci prova).
Non importa la forma in cui scrivi una SELECT, questa viene comunque
riprocessata e ottimizzata prima di essere data in pasto al motore del
DBMS vero e proprio. Nella realtà, ci sarà senza dubbio qualche minima
differenza, ma minima. Insomma, comandi equivalenti, per quanto diversi,
se il preprocessore funzionasse alla perfezione dovrebbero essere
tradotti allo stesso modo.
Cioè tu sostieni che una query del tipo (tradotta in vulgaris):
"seleziona le Anagarfiche con CITTA='VERONA' dalla Tabella Anagrafiche"
abbia la stessa velocità di esecuzione di :
"seleziona le Anagrafiche con CITTA='VERONA' e (TIPO=0 oppure TIPO=1)
dalla Tabella Anagrafiche".
Ovvio che su cento schede neppure mi pongo il problema. Ma su 100.000?
queste non sono due select equivalenti (che danno quindi il medesimo
output) e quindi non necessariamente hanno la stessa velocità di esec.
Cmq in questo caso, anche su 1'000'000 di record, non ti accorgi della
differenza.
Suppongo che su CITTA sia stato creato un indice (mentre su TIPO no).
Facciamo finta che ci siano 1'000 schede di 'VERONA' (0,1%): la select
richiede solo di scorrere un elenco di mille schede e dare il risultato.
Nel secondo caso le schede che vengono lette sono ugualmente 1000, solo
che alcune non vengono stampate (quelle di TIPO>=2).
SI', ci mettono lo stesso tempo.
caso particolare:
se si tratta di un'azienda di VERONA e il 99% delle schede contiene
quella parola, non abbiamo alcun vantaggio nell'uso di quell'indice.
Magari esistono 10 valori equamente distribuiti per il campo TIPO e
allora è stato creato un indice su tale campo.
In tal caso la seconda select potrebbe essere circa 5 volte piu' veloce,
dovendo scartabellare solo tra 200'000 schede (in media).
se non esistono indici, allora ci mettono lo stesso tempo (vanno
analizzate tutte le schede).
INFINE
"seleziona le Anagrafiche con CITTA='VERONA' e (TIPO=0 oppure TIPO=1)
dalla Tabella Anagrafiche".
e
"seleziona le Anagrafiche con (TIPO=0 oppure TIPO=1) e CITTA='VERONA'
dalla Tabella Anagrafiche".
su un DBMS che non perde tempo ad analizzare prima il comando, queste
select potrebbero avere tempi di esecuzione molto diversi,
ma su un DBMS con preprocessore queste sono equivalenti.
in SQL io dico COSA voglio ottenere, non COME voglio che il computer lo
ottenga, fidandomi di come l'interprete del linguaggio è stato implementato.
Con i linguaggi procedurali io indico COME e quindi le prestazioni
variano enormemente in base a cio' che scrivo.
e poi, le prestazioni non sono tutto.
la "manutenibilità" e la possibilità di adattare il lavoro alle nuove
esigenze, le vedo molto piu' importanti
E sulle query complesse come la mettiamo? Meglio relazionare una
Tabella Clienti, magari con un indice univoco intero, oppure una
select con un paio di parametri ed un OR?
non ho capito la domanda.
ciao,
Giacomo
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Un prestito supertasso zero spese? Oggi con Finatel è realtà. Puoi ottenere
fino a 50.000 anche in 24 ore. Scopri Come
*
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7370&d=4-1
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
