Discussion :

[jolt-counter]

Bonjour,

Imaginions qu'on ait 3 relations (R1, R2, R3), R1 a 1M de tuples, R2 50 000 et R3 20.
Le schéma est le suivant
R1 (a_r1) a_r1 est la clé
R2 (a_r2, a_r1) a_r2 est la clé et a_r1 est une référence vers a_r1 de R1
R3 (a_r3, a_r2) a_r3 est la clé et a_r2 est une référence vers a_r2 de R2

Maintenant voici plusieurs requêtes qui renvoient le même résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT a_r1, a_r2, a_r3 FROM R1 NATURAL JOIN R2 NATURAL JOIN R3
SELECT a_r1, a_r2, a_r3 FROM (R1 NATURAL JOIN R2) NATURAL JOIN R3
SELECT a_r1, a_r2, a_r3 FROM R1 NATURAL JOIN (R2 NATURAL JOIN R3)
SELECT a_r1, a_r2, a_r3 FROM R1, R2, R3 WHERE R1.a_r1 = R2.a_r1 AND R2.a_r2 = R3.a_r3

Y a-t-il une différence en termes de performance lorsqu'on exécute ces requêtes ?
Le fait d'utiliser JOIN va-t-il avoir un impact sur l'ordre dans lequel le SGBD va parcourir nos tables (de tailles très différentes) ou son optimisation sera toujours la même peu importe qu'on utilise un WHERE ou un JOIN pour effectuer la jointure ?

Merci

[tatayo]

Bonjour,
Pour moi, et avec un SGBD digne de ce nom, les 4 requêtes sont équivalentes.
Il suffit de comparer les plans d'exécution pour en avoir le cœur net.

Tatayo.

[escartefigue]

Bonjour,
Pour moi, et avec un SGBD digne de ce nom, les 4 requêtes sont équivalentes.
Il suffit de comparer les plans d'exécution pour en avoir le cœur net.

Tatayo.

Oui, et j'ajouterai qu'une jointure explicite qui précise les colonnes (ON) est préférable, pas pour les performances, mais pour la clarté
C'est également moins risqué en cas d'évolution du DDL

[SQLpro]

De même ÉVITEZ ABSOLUMENT LE NATURAL JOIN !!! c'est une source d'emmerdes..... Cela peut exploser les temps,de réponse !

En effet en admettant que vos tables R1, R2, R3 aient la même colonne pour la jointure, alors l'écriture :
FROM R1 NATURAL JOIN R2 NATURAL JOIN R3
c'est pas équivalente à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

FROM R1 JOIN R2 On R1.C = R2.C JOIN R3 ON R2.C = R3.C

mais bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

FROM R1 JOIN R2 ON R1.C = R2.C JOIN R3 ON R1.C = R3.C AND R2.C = R3.C

Et vous vous retrouvez avec une jointure circulaire sans le savoir !!! Et aucune optimisation n'est possible dans ce cas....

A +

[jolt-counter]

Merci pour vos réponses, mais alors au niveau des performances y aura-t-il une différence entre JOIN et WHERE ?

Pour ces 3 requêtes, y aura-t-il une différence de temps d’exécution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SELECT a_r1, a_r2, a_r3 FROM (R1 JOIN R2 ON R1.a_r1 = R2.a_r1) JOIN R3 ON R2.a_R2 = R3.a_r2
SELECT a_r1, a_r2, a_r3 FROM (R2 JOIN R3 ON R2.a_r2 = R3.a_r2) JOIN R1 ON R1.a_r1 = R2.a_r1
SELECT a_r1, a_r2, a_r3 FROM R1, R2, R3 WHERE R1.a_r1 = R2.a_r1 AND R2.a_r2 = R3.a_r3

En d'autres termes, le fait de spécifier un ordre de jointure dans le FROM va-t-il être pris en compte par le SGBD ou va-t-il appliquer le même algo de jointure pour ces 3 requêtes ?

[tatayo]

Comme je le disais, il suffit de demander au moteur le plan d'exécution des 3 requêtes avec EXPLAIN, puis de comparer.
Pour moi ce sera le même pour les trois requêtes.

Tatayo.

[SQLpro]

Merci pour vos réponses, mais alors au niveau des performances y aura t'il une différence entre JOIN et WHERE ?

Pour ces 3 requêtes, y aura t'il une différence de temps d’exécution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
SELECT a_r1, a_r2, a_r3 FROM (R1 JOIN R2 ON R1.a_r1 = R2.a_r1) JOIN R3 ON R2.a_R2 = R3.a_r2
SELECT a_r1, a_r2, a_r3 FROM (R2 JOIN R3 ON R2.a_r2 = R3.a_r2) JOIN R1 ON R1.a_r1 = R2.a_r1

Les parenthèses ne servent à rien... Vous en avez eu un stocke en solde ?
= étant commutatif, que vous fassiez A = B = C ou A = C = B ou B = C = A ou... cela revient au même !
SQL est un langage de requête, c'est à dire que ce que vous écrivez ne sera absolument pas ce qui sera exécuté !
Le SQL est transformé en algèbre relationnelle (sous forme "d'équation" mathématique) et dans un premier temps simplifié, ceci grâce à un algébriseur.
Ensuite l'optimiseur prend le relai pour savoir dans quel ordre effectuer les accès aux données afin de minimiser les ressources utilisées et par la même diminuer les temps de réponse afin de booster les performances.
Au final, avec un bon SGBDR (je parle pas de cette merde de MySQL...) les plans de requêtes doivent être dientiques quelque soit la façon dont vous avez écrit la requête ! (tant que ces différentes écritures sont mathématiquement équivalentes !!!).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
SELECT a_r1, a_r2, a_r3 FROM R1, R2, R3 WHERE R1.a_r1 = R2.a_r1 AND R2.a_r2 = R3.a_r3

En d'autre terme, le fait de spécifier un ordre de jointure dans le FROM va t'il être pris en compte par le SGBD ou va t'il appliquer le même algo de jointure pour ces 3 requêtes ?

Absolument JAMAIS, sauf sur certains SGBD de bidouileurs comme MySQmerde !

A +