Newsgroup: it.comp.appl.access
Titolo: WHERE campo in (select...) costa quanto una serie di OR?

in una query sql avere una marea di or dovrebbe essere abbastanza
oneroso per il motore del db.
ad esempio, ammettiamo che io abbia una query del genere:
select * from tabella
where campo = 1
      or campo = 2
      or campo = 3
      [...]
      or campo = 100
chiaramente per il motore del db è una bella seccatura.
ora ammettiamo che io mi costruisca un'altra tabella dove ci sono 100
record di un campo solo che contiengono i valori numerici da 1 a 100.
costruisco quest'altra query:
select * from tabella
where campo IN (select altrocampo from altratabella)
a parte che è più facile da scrivere (ma non è questo il problema),
secondo voi è anche meno onerosa come richiesta di risorse?
--
non studio non lavoro non guardo la tv
non vado al cinema non faccio sport
----------------------------------------
il sito comune di it.comp.appl.access:
http://www.sitocomune.com

 secondo voi è anche meno onerosa come richiesta di risorse?
personalmente non ho mai effettuato dei test, ma molti nomi autorevoli dicono
che le query innestate sono piu' onerose; in particolare, se si deve stare
attenti alle prestazioni, e' sempre meglio trasformare questo tipo di query in
una con piu' join.
per quanto riguarda il tuo esempio, ok per la seconda tabella, ma la query:
SELECT * FROM altratabella INNER JOIN tabella ON altratabella.campo =
tabella.campo
dovrebbe essere piu' veloce della query innestata.
resta da vedere se e' anche piu' veloce della prima.
-- 
Federico
----------------------------------
Rimuovi paperino. per e-mail
----------------------------------
Tutte le richieste che arrivano
in privato, vengono cestinate.
----------------------------------
Sito Comune di it.comp.appl.access
http://www.sitocomune.com
mailto:
webm...@sitocomune.com
----------------------------------

 secondo voi č anche meno onerosa come richiesta di risorse?
Ci sarebbe anche un'altra soluzione: scrivere una funzione che fa quei
controlli tornando true e false e metti come criterio la chiamata alla
funzione con parametro il campo.
Anche questo "dovrebbe" essere meno oneroso...
Antonio

 una con piu' join.
La mia esperienza a rigurado e' diversa, soprattutto se i join sono molti.
Qualche tempo fa ho guadagnato mostruosmente in prestazioni (50 sec contro
5) nidificando appunto una query. Resta inteso che gli indici giocano un
ruolo fondamentale. Se non ricordo male e' proprio uno dei consigli
dell'help circa l'ottimizzazione delle query.
Saluti.
lucia...@sitocomune.com

 secondo voi è anche meno onerosa come richiesta di risorse?
La risposta puoi darla solo tu facendo delle prove!:-)
Quello che posso dirti per esperienza e' che gli inselect si sdraiano se
sono piu' di uno o se hanno dei where al loro interno.
Una buona indicizazione inoltre ha la sua parte.
A raggruppare le condizioni (>10 anziche = 1 or  =2 ecc) hai gia'
provato?Saluti.
Saluti.
lucia...@sitocomune.com


di che dbms stai parlando? non tutti si comportano allo stesso modo. ce
ne' qualcuno che quando trova or o in anche se ha indici non li usa e fa
cmq un tablescan.
-- 
Alessandro Cara
PS in accesss mi sembra che le select innestate certe volte sono molto
piu' sveglie delle join. Mi e' capitato un paio di volte che con la join
(anche se io uso il metodo con la where) mi ha detto "gnafo'" mentre con
la select innestata e' andato che e' una bellezza. Ah dimenticavo il
prodotto cartesiano puro avrebbe generato circa 9 milioni di righe.

 news:3a7a1922...@news.edisons.it...
sorry la mia precedente era per Lbo. Ho sbagliato l'aggancio.
-- 
Alessandro Cara

piu' sveglie delle join. Mi e' capitato un paio di volte che con la join
eh, appunto, avevo sta sensazione...  ma volevo altri pareri...


 --
E se invece si crea una tabella temporanea con i parametri e si linkano i
valori di questi al campo da testare? (Spero di essere stato chiaro :-))
Daniele "Antares" Fasoli
fas...@easy1.easynet.it

Anche questo "dovrebbe" essere meno oneroso...
a dire il vero tutto ciò mi serve in un'applicazione asp, e non posso
usare funzioni custom in una stringa sql così come si può fare con
access, sennò era una buona idea anche questa.


 access, sennò era una buona idea anche questa.
Non ho seguito il post. Cmq mi sembra (devo verificare) che sia possibile
creare, in access, delle query che richiamano funzioni presenti nello stesso
DB. A quel punto, da ASP, basterebbe richiamare quelle query.
Ripeto, non sono sicurissimo che funzioni, ma non vedo perchè non dovrebbe.
E cmq non se se questo è il caso che fa per te.

DB. A quel punto, da ASP, basterebbe richiamare quelle query.
l'idea č buona e funzionerebbe, il problema č che bisogna creare delle
query predefinite direttamente sul file di access, cioč tirarlo giů,
metterci le query e riuploadarlo, e questo non č sempre pratico.
comunque grazie del suggerimento!
