SQL: Join come funziona dietro le quinte?

[jabjoint]

Una domanda banale da inesperto,
Come funziona la Join (SQL) dietro le quinte?
Ad esempio perché è più veloce una Join rispetto a richiamare due select per estrarre i dati?
(Se è così?)
In quali casi va sempre usata? Ed in quali evitata?
Grazie e buona serata

[Sonikag]

Una domanda banale da inesperto,
Come funziona la Join (SQL) dietro le quinte?

La Join è un unione di due (o più tabelle).

Ad esempio perché è più veloce una Join rispetto a richiamare due select per estrarre i dati?
(Se è così?)

Sono due cose diverse! Due select di restituiscono due diverse tabelle, la join te le unisce associandole. In ogni caso meno query e meno operazioni si fanno fare più guadagneremo in velocità. Poi con pochi dati la differenza non si nota.

In quali casi va sempre usata? Ed in quali evitata?
Grazie e buona serata

Non ha controindicazioni! Va usata quando serve e non va usata se non serve è come i fendinebbia

Ciao anche a te!

[URANIO]

Che io sappia, Due select sono piu veloci di una join, a meno che tu non ti riconnetta ogni volta che le esegui

[Joe Taras]

Che io sappia, Due select sono piu veloci di una join, a meno che tu non ti riconnetta ogni volta che le esegui

Come ha già risposto Sonikag, sono due operazioni diverse.

Eseguo due query distinte, se voglio vedere informazioni di due tabelle differenti, senza che siano in relazione. Eseguo una JOIN per vedere informazioni di entrambe le tabelle, decidendo se una delle due è quella principale ed l'altra facoltativa (OUTER JOIN), o hanno entrambe la stessa "dingità" (INNER JOIN).

Ovviamente una JOIN è più complessa a livello computazionale di una query con singola tabella

[optime]

Che io sappia, Due select sono piu veloci di una join, a meno che tu non ti riconnetta ogni volta che le esegui

FORSE sono più veloci, ma poi brasi cervello e server per connetterle. Le JOIN esistono, usatele

[URANIO]

Ad esempio perché è più veloce una Join rispetto a richiamare due select per estrarre i dati?

Il mio era um commento a questa frase.

[optime]

e allora non l'ho capito...

[marino51]

nel secolo scorso, sviluppai un'applicazione in C che,
leggendo dal db generava una matrice di valori
applicava un algoritmo matematico
infine memorizzava il risultato


i pc, significativamente lenti per le caratteristiche del tempo,
presentavano tempi di esecuzione gravosi


nella necessità di ridurre i 48 secondi, causati da 225 letture al db (singole select),
decisi di usare delle select con join di tabelle, come unica azione che mi era possibile


fui costretto a modificare delle sub aumentando di 200 linee il programma
da 1500 righe a 1700, ma così facendo ridussi a 9 le letture al db (select in join)


il beneficio fu evidente, ottenendo un tempo di preparazione della matrice di 14 secondi


per l'analisi dell'eseguibile usai PLIST un tool di Microsoft, di cui riporto il risultato


questa analisi é stata la via che ho seguito nel tempo, cercando di ridurre gli accessi al db
anche a costo di creare query con join complesse


ovviamente, tutte le analisi dell'exe sono state fatte a pc riavviato ogni volta,
le tabelle erano ben indicizzate e l'indicizzazione non é mai stata modificata durante le analisi

FR12 -- Vers. 03.1 ------------------------------


tempo di preparazione    :  48 sec
tempo di calcolo         :  0 sec
tempo di memor.risultato :  5 sec
tempo totale di elab.ne  :  53 sec


FINE DEL PROGRAMMA




Microsoft PLIST Version 1.00
Profile: Function timing, sorted by time.
Program Statistics
Total time: 57542.664 milliseconds
Time outside of functions: 179.013 milliseconds
Call depth: 8
Total functions: 29
Total hits: 664
Function coverage: 79.3%
Module Statistics for fr12.exe
Time in module: 57363.651 milliseconds
Percent of time in module: 100.0%
Functions in module: 29
Hits in module: 664
Module function coverage: 79.3%


     Func         Func+Child            Hit
     Time      %        Time       %  count    Function


37687.180   65.7   37687.180    65.7	225    sub_comp_for_2       (fr12o.c:892)
 6864.491   12.0    6864.491    12.0     25    sub_comp_for_3       (fr12o.c:926)
 3338.205    5.8    3340.597     5.8     25    sub_upd_comp         (fr12o.c:1361)
 3067.577    5.3   51004.538    88.9     10    sub_comp_for         (fr12o.c:816)
 1427.693    2.5   50287.469    87.7      2    sub_car_for          (fr12o.c:709)
 1045.403    1.8    1405.170     2.4      1    sub_calcolo          (fr12o.c:1090)
....




FR12 -- Vers. 03.2 ------------------------------


tempo di preparazione    :  14 sec
tempo di calcolo         :  0 sec
tempo di memor.risultato :  3 sec
tempo totale di elab.ne  :  17 sec


FINE DEL PROGRAMMA 




Microsoft PLIST Version 1.00
Profile: Function timing, sorted by time.
Program Statistics
Total time: 19592.594 milliseconds
Time outside of functions: 399.423 milliseconds
Call depth: 10
Total functions: 33
Total hits: 478
Function coverage:  78.8%
Module Statistics for fr12.exe
Time in module: 19193.171 milliseconds
Percent of time in module: 100.0%
Functions in module: 33
Hits in module: 478
Module function coverage: 78.8%


     Func         Func+Child            Hit
     Time      %        Time       %  count    Function


 7258.117   37.8   13607.582    70.9      9    sub_comp_for_a  (fr12.c:922)
 4032.109   21.0    4032.109    21.0     47    sub_upd_comp_1  (fr12.c:1534)
 3772.645   19.7    6312.133    32.9     25    sub_comp_for_3  (fr12.c:1074)
  694.260    3.6   14304.358    74.5      9    sub_car_for_1   (fr12.c:860)
....

[Joe Taras]

nel secolo scorso, sviluppai un'applicazione in C che,
leggendo dal db generava una matrice di valori
applicava un algoritmo matematico
infine memorizzava il risultato


i pc, significativamente lenti per le caratteristiche del tempo,
presentavano tempi di esecuzione gravosi


nella necessità di ridurre i 48 secondi, causati da 225 letture al db (singole select),
decisi di usare delle select con join di tabelle, come unica azione che mi era possibile


fui costretto a modificare delle sub aumentando di 200 linee il programma
da 1500 righe a 1700, ma così facendo ridussi a 9 le letture al db (select in join)


il beneficio fu evidente, ottenendo un tempo di preparazione della matrice di 14 secondi


per l'analisi dell'eseguibile usai PLIST un tool di Microsoft, di cui riporto il risultato


questa analisi é stata la via che ho seguito nel tempo, cercando di ridurre gli accessi al db
anche a costo di creare query con join complesse


ovviamente, tutte le analisi dell'exe sono state fatte a pc riavviato ogni volta,
le tabelle erano ben indicizzate e l'indicizzazione non é mai stata modificata durante le analisi

FR12 -- Vers. 03.1 ------------------------------


tempo di preparazione    :  48 sec
tempo di calcolo         :  0 sec
tempo di memor.risultato :  5 sec
tempo totale di elab.ne  :  53 sec


FINE DEL PROGRAMMA




Microsoft PLIST Version 1.00
Profile: Function timing, sorted by time.
Program Statistics
Total time: 57542.664 milliseconds
Time outside of functions: 179.013 milliseconds
Call depth: 8
Total functions: 29
Total hits: 664
Function coverage: 79.3%
Module Statistics for fr12.exe
Time in module: 57363.651 milliseconds
Percent of time in module: 100.0%
Functions in module: 29
Hits in module: 664
Module function coverage: 79.3%


     Func         Func+Child            Hit
     Time      %        Time       %  count    Function


37687.180   65.7   37687.180    65.7    225    sub_comp_for_2       (fr12o.c:892)
 6864.491   12.0    6864.491    12.0     25    sub_comp_for_3       (fr12o.c:926)
 3338.205    5.8    3340.597     5.8     25    sub_upd_comp         (fr12o.c:1361)
 3067.577    5.3   51004.538    88.9     10    sub_comp_for         (fr12o.c:816)
 1427.693    2.5   50287.469    87.7      2    sub_car_for          (fr12o.c:709)
 1045.403    1.8    1405.170     2.4      1    sub_calcolo          (fr12o.c:1090)
....




FR12 -- Vers. 03.2 ------------------------------


tempo di preparazione    :  14 sec
tempo di calcolo         :  0 sec
tempo di memor.risultato :  3 sec
tempo totale di elab.ne  :  17 sec


FINE DEL PROGRAMMA 




Microsoft PLIST Version 1.00
Profile: Function timing, sorted by time.
Program Statistics
Total time: 19592.594 milliseconds
Time outside of functions: 399.423 milliseconds
Call depth: 10
Total functions: 33
Total hits: 478
Function coverage:  78.8%
Module Statistics for fr12.exe
Time in module: 19193.171 milliseconds
Percent of time in module: 100.0%
Functions in module: 33
Hits in module: 478
Module function coverage: 78.8%


     Func         Func+Child            Hit
     Time      %        Time       %  count    Function


 7258.117   37.8   13607.582    70.9      9    sub_comp_for_a  (fr12.c:922)
 4032.109   21.0    4032.109    21.0     47    sub_upd_comp_1  (fr12.c:1534)
 3772.645   19.7    6312.133    32.9     25    sub_comp_for_3  (fr12.c:1074)
  694.260    3.6   14304.358    74.5      9    sub_car_for_1   (fr12.c:860)
....

Ciao,
ovviamente hai preso una strada giusta, perché hai ridotto sensibilmente i tempi, in questo caso usando delle JOIN.

Vorrei sottolineare che non esiste una soluzione ottimale in assoluto, ma tutto va contestualizzato.

Nelle applicazioni OLTP è utilizzo adoperare le JOIN e tutti gli altri costrutti che riducono i tempi, ad esempio l'utilizzo in alcuni casi delle clausole di EXISTS e NOT EXISTS, che filtrano i dati (talvolta si usano le JOIN per tagliare alcuni dati, esempio delle INNER, ma appesantendo i tempi di esecuzione).

Nelle applicazioni OLAP invece, si evita il più possibile il ricorso alle JOIN ma perché la base di dati per i datawarehouse è denormalizzata (volutamente)

[jabjoint]

Ciao,
ovviamente hai preso una strada giusta, perché hai ridotto sensibilmente i tempi, in questo caso usando delle JOIN.

Vorrei sottolineare che non esiste una soluzione ottimale in assoluto, ma tutto va contestualizzato.

Nelle applicazioni OLTP è utilizzo adoperare le JOIN e tutti gli altri costrutti che riducono i tempi, ad esempio l'utilizzo in alcuni casi delle clausole di EXISTS e NOT EXISTS, che filtrano i dati (talvolta si usano le JOIN per tagliare alcuni dati, esempio delle INNER, ma appesantendo i tempi di esecuzione).

Nelle applicazioni OLAP invece, si evita il più possibile il ricorso alle JOIN ma perché la base di dati per i datawarehouse è denormalizzata (volutamente)

Ringrazio tutti dell' aiuto, anche se non ho ancora chiarito al 100% ho idee un pochino più limpide.
Buon fine settimana