Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SQL - ricerce e join su tre tabelle
181 views
Skip to first unread message
Daniele
Jul 13, 2016, 12:52:29 PM7/13/16
to
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
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
Giacomo Degli Esposti
Jul 14, 2016, 4:29:24 AM7/14/16
to
On Wednesday, July 13, 2016 at 6:52:29 PM UTC+2, Daniele wrote:
[...]
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
[...]
> 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)
Se si tratta di un problema di database (dici che e' lento anche
> 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)
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
Daniele
Jul 14, 2016, 11:14:32 AM7/14/16
to
Ciao Giacomo,
> Se si tratta di un problema di database (dici che e' lento anche
> usando DBEaver) cosa c'entra Delphi? :-)
Niente, e' solo per rimarcare il pseudo problema in entrambi gli ambienti.
> Detto questo, che DB stai usando?
Piccola dimenticanza !!!!
Il db in uso e' firebird 2.5
Come avevo gia' anticipato tempo fa e' probabile che a gennaio 2017 ci
sara' un passaggio alla versione 3.
> 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.
Il fatto e' che non so come trovare se i dati salvati in Tabella1 (e' la
tabella dove presumibilmente vengono salvati i documenti in uscita)
contengono o meno una certa stringa.
In alcune fatture emesse viene applicato uno sconto, lo sconto (e il perche'
e' stato applicato) viene salvato nel campo commento (anche un po limitato),
dove sta il problema?
Il problema e' di come viene compilato il commento, c'e' chi scrive "sconto
del 5% ....2", chi scrive "scont. 5", insomma non c'e' una direttiva
univoca.
> Hai provato a vedere se cambia qualcosa togliendo la clausola
> su COMMENTO e filtrando i dati da client Delphi?
No, pero' se la nota di sconto applicato e' salvato nel campo COMMENTO, non
ho molte altre opzioni !
Pero' se ci sono altre opzioni ...
> (sperando di riportare IT il thread... ;)
Questo mi suona strano !
Dovremmo essere gia' IT, o sbaglio ?
Grazie
Ciao
Daniele
> 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 in uso e' firebird 2.5
Come avevo gia' anticipato tempo fa e' probabile che a gennaio 2017 ci
sara' un passaggio alla versione 3.
> 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.
tabella dove presumibilmente vengono salvati i documenti in uscita)
contengono o meno una certa stringa.
In alcune fatture emesse viene applicato uno sconto, lo sconto (e il perche'
e' stato applicato) viene salvato nel campo commento (anche un po limitato),
dove sta il problema?
Il problema e' di come viene compilato il commento, c'e' chi scrive "sconto
del 5% ....2", chi scrive "scont. 5", insomma non c'e' una direttiva
univoca.
> Hai provato a vedere se cambia qualcosa togliendo la clausola
> su COMMENTO e filtrando i dati da client Delphi?
ho molte altre opzioni !
Pero' se ci sono altre opzioni ...
> (sperando di riportare IT il thread... ;)
Dovremmo essere gia' IT, o sbaglio ?
Grazie
Ciao
Daniele
Giacomo Degli Esposti
Jul 15, 2016, 4:20:14 AM7/15/16
to
On Thursday, July 14, 2016 at 5:14:32 PM UTC+2, Daniele wrote:
> Il db in uso e' firebird 2.5
OK. Purtroppo non conosco a sufficienza fb per darti delle
> Il db in uso e' firebird 2.5
soluzioni alternative specifiche per quel db.
> > 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.
> Il fatto e' che non so come trovare se i dati salvati in Tabella1 (e' la
> tabella dove presumibilmente vengono salvati i documenti in uscita)
> contengono o meno una certa stringa.
> In alcune fatture emesse viene applicato uno sconto, lo sconto (e il perche'
> e' stato applicato) viene salvato nel campo commento (anche un po limitato),
> dove sta il problema?
> Il problema e' di come viene compilato il commento, c'e' chi scrive "sconto
> del 5% ....2", chi scrive "scont. 5", insomma non c'e' una direttiva
> univoca.
tutti di dover affrontare :-)
Il problema e' come ti accennavo che i DB in genere NON gestiscono
bene questa condizione (il like '%xyz%' fa disastri)
e a meno che fb non abbia qualche modo particolare per gestire
questa problematica in modo efficiente sei fregato... :-(
Anche perche' il problema e' chiaramente su fb. Il fatto
che e' lento anche usando DBeaver dovrebbe darti un indizio.
Secondo me devi lavorare sulla base dati. Ci sono degli indici
sulle tabelle? Sul campo GIORNO e sui campi chiave?
> > Hai provato a vedere se cambia qualcosa togliendo la clausola
> > su COMMENTO e filtrando i dati da client Delphi?
> No, pero' se la nota di sconto applicato e' salvato nel campo COMMENTO, non
> ho molte altre opzioni !
> Pero' se ci sono altre opzioni ...
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
Warp10
Jul 15, 2016, 4:44:14 AM7/15/16
to
Il 14/07/2016 17.14, Daniele ha scritto:
> Pero' se ci sono altre opzioni ...
Se hai accesso alle righe dei documenti emessi puoi confrontare la somma
> Pero' se ci sono altre opzioni ...
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
Daniele
Jul 15, 2016, 4:52:05 AM7/15/16
to
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
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
Giacomo Degli Esposti
Jul 15, 2016, 5:47:20 AM7/15/16
to
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
David Lastrucci
Jul 15, 2016, 9:27:20 AM7/15/16
to
Ciao Giacomo,
> 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!
Di solito dovrebbe essere cosě, ma magari FB li tratta in base all'ordine :-P
David
> 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!
David
Daniele
Jul 16, 2016, 5:13:17 AM7/16/16
to
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
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
Morde
Jul 18, 2016, 5:45:20 AM7/18/16
to
On 16.07.2016 11:13, Daniele wrote:
> 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.
Hai verifica con il PLAN che cosa succede invertendo i parametri?
> 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.
http://www.firebirdsql.org/manual/isql-set.html#isql-set-plan
--
Morde
0 new messages