Newsgroup: it.comp.lang.delphi
Titolo: SQL - ricerce e join su tre tabelle

Ciao a tutti,
  ho tre tabelle da dove devo recuperare i dati.
I dati vengono recuperati tramite 2 join e una ricerca selettiva sulla prima 
tabella, le tre tabelle sono (i nomi sono realmente questi) Tabella1, 
Tabella2, Tabella3
 
Il campo principe e' il campo CODICE2 della tabella1 definito come integer.
Non si sa il perche' nella Tabella2 lo stesso campo CODICE2 e' defino come 
string (VARCHAR(10))
Infine la Tabella2 tramite il campo NUMERO e' collegata alla Tabella3 dove, 
finalmente, ho le informazioni che mi servono.
 
Uno dei problemi e' che non tutti i record della Tabella2 hanno il campo 
CODICE2 con un valore, a volte sono vuoti ('') o NULL e quindi genera un 
errore di conversione.
 
Ho pensato a questa query, che funziona,  provata oltre che con Seattle 
anche con DBeaver, ma risulta essere un po lenta (da entrambe le parti).
Select * from  Tabella1 inner join  Tabella2 ON 
Tabella1.CODICE2=Tabella2.CODICE2 INNER JOIN Tabella3 ON 
Tabella2.NUMERO=Tabella3.NUMERO where ( (Tabella2.CODICE2<>'') and 
Tabella1.COMMENTO LIKE '%sco%' AND Tabella1.GIORNO='07/04/2016' )
 
In effetti la ricerca si chiude filtrando per il giorno indicato e cercando 
la presenza di una stringa digitata dall'utente nel campo commento definto 
come string (VARCHAR(200)).
 
Tempo della ricerca 1,6 secondi (intel core i5 2400 3.10 GHz con 4 GB Ram)
 
Tabella1 solo 1000 record; Tabella2 105000 record (circa ed in aumento); 
Tabella3 150000 (circa ed in aumento)
 
Non mi sembrano tabelle esageratamente grandi !!!
 
Suggerimenti ?
 
Grazie a tutti
 
Ciao
 
Daniele
 
 

 Tabella3 150000 (circa ed in aumento)
 
Se si tratta di un problema di database (dici che e' lento anche 
usando DBEaver) cosa c'entra Delphi? :-)
 
Detto questo, che DB stai usando? Il DB non la libreria di
accesso ai dati, quindi non voglio sapere se usi BDE o DBX o ADO... 
 
Il problema e' probabilmente il LIKE '%sco%' che in tutti i DB
che conosco (pochi) forza un table scan di tutti i dati perche
non puo usare indici. 
 
Hai provato a vedere se cambia qualcosa togliendo la clausola
su COMMENTO e filtrando i dati da client Delphi? (sperando
di riportare IT il thread... ;)  
 
ciao
Giacomo
 
 
 
 
 
 

 (sperando di riportare IT il thread... ;)
Questo mi suona strano !
Dovremmo essere gia' IT, o sbaglio ?
 
Grazie
 
Ciao
 
Daniele
 
 
 
 
 

 Pero' se ci sono altre opzioni ...
 
No, infatti non ne vedo molte altre. E non so nemmeno se filtrare
i dati da client (usando Filter o OnFilterRecord sui dataset)
sia una soluzione davvero efficace, in teoria dovrebbe essere 
piu' veloce il server a fare questo filtro, piuttosto
che spostare attraverso la rete tutti i dati e poi filtrarli
sul client, ma io lo farei un esperimento, non si sa mai! :-D
 
ciao
Giacomo

 Pero' se ci sono altre opzioni ...
 
Se hai accesso alle righe dei documenti emessi puoi confrontare la somma 
dei loro importi col totale del documento e così sai se è stato 
applicato uno sconto o meno.
 
-- 
@WarpTen10
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

Ciao Giacomo,
     ti ringrazio per l'attenzione e alla fine ho deciso di tenere tutto 
cosi'.
Alla fine anche se il DB cresce in modo spropositato l'interrogazione 
avviene DATA, poi per l'imput dell'utente.
Potrebbe sembrare strano, ma invertendo i parametri nella query, cioe' prima 
metto la data e dopo la ricerca nel campo commento, il risultato e' 
pressoche' istantaneo (forse perche' esiste un indice sul campo data).
 
Grazie ancora
 
Ciao
 
Daniele 
 


Cado dalle nubi (cit) :-o
 
Nei DB che conosco l'ordine delle condizioni nel Where non ha alcuna
importanza, userebbero l'indice a prescindere dall'ordine in cui compaiono!
 
Comunque se hai trovato una soluzione, meglio cosi'! :-D
 
ciao
Giacomo
 
 
 

 compaiono!
 
Di solito dovrebbe essere cosě, ma magari FB li tratta in base all'ordine :-P
 
David
 
 

Ciao,

Per quanto puo' essere strano, non comprensibile ecc.. sul mio pc e' quello 
che accade.
Invertendo il criterio di ricerca si passa da 0,7 sec. a 1,2 sec.
 
Probabilmente ci saranno delle presenze mistiche nella scheda del pc (ho 
controllato per sicurezza anche con pokemon go ... nel pc non ci sono 
:-))) )
 
Buon fine settimana
 
ciao
 
Daniele
 

 Invertendo il criterio di ricerca si passa da 0,7 sec. a 1,2 sec.
 
Hai verifica con il PLAN che cosa succede invertendo i parametri?
http://www.firebirdsql.org/manual/isql-set.html#isql-set-plan
 
 
-- 
Morde