problema con query annidate

[deleted_b]

access, sto facendo delle prove di prestazioni per scegliere tra diverse soluzioni

ho due tabelle tab e tab2 popolate con 200000 numeri interi +- casuali, ogni campo è indicizzato... misuro i tempi di ogni query

rs.Open "select * from tab", objConn, adOpenKeyset, adLockOptimistic, adCmdText
response.write rs.recordcount
> ok, veloce

rs.Open "select distinct ccc from tab2 where ccc=5", objConn, adOpenKeyset, adLockOptimistic, adCmdText
response.write rs.recordcount
> ok, veloce

il problema nasce quando le annido

rs.Open "select tab.* from tab where tab.aaa not in (select distinct tab2.ccc from tab2 where tab2.ccc=5)", objConn, adOpenKeyset, adLockOptimistic, adCmdText

fin qui ok, veloce

appena provo ad eseguire rs.recordcount o a scorrere il recordset mi si impalla tutto

cosa mi sta sfuggendo?! grazie

[deleted_b]

ora "invertendo" la query e togliendo distinct

rs.Open "select tab.* from tab where tab.aaa in (select tab2.ccc from tab2 where tab2.ccc<>5)", objConn, adOpenKeyset, adLockOptimistic, adCmdText

pare veloce... dipende tutto da "not in"!?!?!?

[deleted_b]

invece di usare distinct nelle query annidate meglio group by

rs.Open "select tab.* from tab where tab.ccc in (select tab2.ccc from tab2 where tab2.ccc<>5 group by tab2.ccc)"

ecco risolto... il problema era la distinct... ora devo capire perchè in una query annidata pianta tutto... non ci si pensa mica

[optime]

se tu hai 1 milione di record, e solo uno con tab2.ccc=5.... dai che ci arrivi da solo


(per inciso, la WHERE...IN(...) è una delle operazioni più faticose per il server, fa' una JOIN)

[deleted_b]

bhè ovvio... nella realtà dovrò cancellare record di una tabella in base a dei valori presenti in un'altra tabella... da qui questo test di prestazioni per diverse soluzioni

non è che quella chiavica di access rielabora la select annidata ogni volta per ogni record?!?!?

[optime]

Originariamente inviato da cicciopie II
non è che quella chiavica di access rielabora la select annidata ogni volta per ogni record?!?!?

non è *quella chiavica*. è il programmatore che ha sbagliato query! la WHERE...IN viene *sviluppata*, per cui la

select * from tabella where codice in (select codice from tabella2)

diventa

select * from tabella where codice in ('cod1', 'cod2', 'cod3',...,'codN')

se in tabella2 ci sono milioni di codici, ecco che la select rallenta (non c'entra access, succederebbe con *qualunque* db).

[deleted_b]

comunque la not in con un solo valore è più lenta rispetto alle query invertita con più valori da controllore

[optime]

Originariamente inviato da cicciopie II
comunque la not in con un solo valore è più lenta rispetto alle query invertita con più valori da controllore

che vuol dire 'con un solo valore' ?

[deleted_b]

Originariamente inviato da optime
non è *quella chiavica*. è il programmatore che ha sbagliato query! la WHERE...IN viene *sviluppata*, per cui la

select * from tabella where codice in (select codice from tabella2)

diventa

select * from tabella where codice in ('cod1', 'cod2', 'cod3',...,'codN')

se in tabella2 ci sono milioni di codici, ecco che la select rallenta (non c'entra access, succederebbe con *qualunque* db).

questo è chiaro... infatti usavo distinct per ottimizzare

select * from tabella where codice in (select distinct codice from tabella2) > si impalla

select * from tabella where codice in (select codice from tabella2 group by codice) > veloce

uno non ci pensa mica, visto che il risultato della subquery è lo stesso... inoltre, not in rallenta ancora di un 50% sul mio test... eppure la subquery restituiva un solo valore (caso migliore)

[deleted_b]

Originariamente inviato da optime
che vuol dire 'con un solo valore' ?

... not in (5) ... più lenta di un 50% rispetto a ... in (1,2,3,4,6,7,8,9,10) ... perchè?! dipenderà dalla distrubuzione casuale dei numeri?!