Discussion :

[Ry_Yo]

Bonjour à tous,

J'aurais aimé savoir si le fait de placer ces critères de recherche dans le JOIN optimise une requête...

En fait je me suis toujours imaginé (peut-être à tort...) que si je mettais les clauses dans le JOIN, les sous-ensembles généré était plus petit et donc sur une jointure le temps d'exécution serait plus rapide...

Donc pour résumer est-ce qu'il y a une réelle optimisation si j'écris ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
SELECT * 
 
FROM TABLE_A
      INNER JOIN TABLE_B
            ON (TABLE_A.IdA = TABLE_B.IdA
            AND TABLE_A.nom = 'AAA'
            AND TABLE_A.Date > '20090313')
      INNER JOIN TABLE_C
            ON (TABLE_C.IdB = TABLE_B.IdB)

plutôt que ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
SELECT * 
 
FROM TABLE_A
       INNER JOIN TABLE_B
            ON (TABLE_A.IdA = TABLE_B.IdA)
       INNER JOIN TABLE_C
            ON (TABLE_C.IdB = TABLE_B.IdB)
 
WHERE TABLE_A.nom = 'AAA'
AND TABLE_A.Date > '20090313'

Merci de vos avis éclairés

[jbrasselet]

Il me semble que cela ne change rien question optimisation.
Les SGBD ont de toutes façons des optimisateurs de requêtes.
C'est plus une façon de présenter.

En espérant ne pas dire de bêtises

[cavo789]

Je n'ai jamais pensé à ce que la première solution que tu indiques puisse exister (ça fonctionne vraiment???).

La bonne méthode de faire est d'utiliser les JOIN pour faire les liaisons entre tes tables et seules les critères de sélection dans la condition WHERE. A cette fin, ta deuxième proposition est la meilleure.

En ce qui concerne l'optimisation pure; je me rallierais également à l'idée de jbrasselet en pensant que l'optimisation sera correctement réalisée par le moteur de requête de SQL Server.

[CinePhil]

Idem mes deux collègues...

Syntaxe :

Code :

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

1
2
3
4
5
6
7
SELECT colonnes
FROM tableA
JOIN tableB ON condition de joitnure
WHERE condition de restriction
GROUP BY colonnes du select sans opération
HAVING condition de restriction sur le regroupement
ORDER BY ordre

[Ry_Yo]

Je n'ai jamais pensé à ce que la première solution que tu indiques puisse exister (ça fonctionne vraiment???).
...

En tout cas cela fonctionne parfaitement sous sql server, j'en suis naturellement arrivé à cette forme d'écriture pour les raisons exposés plus haut et aussi lorsque que je faisais de la maintenance de mon code... Je me trouvais plus compréhensible quand à la relecture des requêtes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
SELECT * 
 
FROM TABLE_A
       INNER JOIN TABLE_B
            ON (TABLE_A.IdA = TABLE_B.IdA)
       INNER JOIN TABLE_C
            ON (TABLE_C.IdB = TABLE_B.IdB)
 
WHERE TABLE_A.nom = 'AAA'
AND TABLE_A.Date > '20090313'

en lisant le code ligne à ligne :
- je vois un gros jeu de résultat de 3 tables liés
- puis de cette ensemble j'extrais un sous-ensemble selon mes 2 critères
- du coup je faisais une réflexion supplémentaire pour savoir de quel table provenait les critères et avec quelle table la jointure avait été faite....

tandis qu'avec l'autre syntaxe :

Code :

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

1
2
3
4
5
6
7
8
9
SELECT * 
 
FROM TABLE_A
      INNER JOIN TABLE_B
            ON (TABLE_A.IdA = TABLE_B.IdA
            AND TABLE_A.nom = 'AAA'
            AND TABLE_A.Date > '20090313')
      INNER JOIN TABLE_C
            ON (TABLE_C.IdB = TABLE_B.IdB)

en lisant le code ligne à ligne :
-Je vois un ensemble de résultat entre A et B avec des restrictions
- Le résultat de A et B je le relie à C

je sais pas si je suis clair dans ce que j'explique... Mais du coup je trouve que la comprehension de la requête m'est plus facile avec cette 2ème syntaxe...Enfin en gros c'est comme ça que fonctionne mon cerveau quand je lis une requête....

Bref pour résumer je me pause donc un faux problème alors... Pas d'optimisation... Par contre la requête n'est pas aux normes....

Merci de vos réponses.

[Fleur-Anne.Blain]

Le résolu c'est le petit bouton en bas de la conversation qui ressemble à

[Keihilin]

Je n'ai jamais pensé à ce que la première solution que tu indiques puisse exister (ça fonctionne vraiment???).

La bonne méthode de faire est d'utiliser les JOIN pour faire les liaisons entre tes tables et seules les critères de sélection dans la condition WHERE. A cette fin, ta deuxième proposition est la meilleure.

Question de culture et d'habitude sans doute, mais moi ça ne me choque pas de "raffiner" les conditions de jointure sous la forme de la première proposition.

Par ailleurs, je me souviens avoir rencontré quelques cas (sous Oracle il me semble) avec certains type de jointure (externe je crois) où la première forme ne de donnait pas les mêmes résultats que la seconde...

[CinePhil]

Je ne sais pas si c'est à ça que tu fais allusion mais il s'agit dans cet article d'une discussion sur la différence de résultat que peut produire l'ancienne syntaxe (FROM a, b WHERE a.id = b.idA), encore trop souvent vue, par rapport à la syntaxe normalisée depuis 1992 (FROM a JOIN b ON a.id = b.idA).

Lecture très instructive qui devrait finir de vous convertir à la séparation entre condition de jointure et condition de restriction.

[Keihilin]

Non, j'ai lu cet article et je savais que l'ancienne syntaxe produit parfois des résultats différents.

Là je parle d'un cas que j'ai rencontré où

Code :

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

1
2
3
4
5
6
7
8
9
 
select 
 * 
from
 TABLE_A
      left outer join TABLE_B
            on (TABLE_A.IdA = TABLE_B.IdA
            and TABLE_A.champ1 = 'XYZ'
            and TABLE_A.champ2 > 'ABC')

ne donnait pas le même résultat que

Code :

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

1
2
3
4
5
6
7
8
9
10
 
select 
 * 
from
 TABLE_A
      left outer join TABLE_B
            on TABLE_A.IdA = TABLE_B.IdA
where
 TABLE_A.champ1 = 'XYZ'
 and TABLE_A.champ2 > 'ABC'

mais je ne me souviens pas exactement de la requête, je me souviens juste que c'était sous Oracle...

[Waldar]

Vos deux requêtes donneront le même résultat, et ce n'est pas propre à Oracle, c'est l'écriture normalisée.

Mettre les conditions de jointure dans la jointure n'est réellement utile qu'en cas de jointure externe : OUI.
Mais encore faut-il que les filtres s'applique sur cette table : dans vos deux exemples les filtres sont sur la table "maître".

Code :

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

1
2
3
4
5
6
7
SELECT * 
FROM
    TABLE_A
    LEFT OUTER JOIN TABLE_B
      ON TABLE_A.IdA = TABLE_B.IdA
     AND TABLE_B.champ1 = 'XYZ'
     AND TABLE_B.champ2 > 'ABC'

Est équivalent à :

Code :

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

1
2
3
4
5
6
7
SELECT * 
FROM
    TABLE_A as A
    LEFT OUTER JOIN (SELECT * from TABLE_B
                     WHERE TABLE_B.champ1 = 'XYZ'
                     AND TABLE_B.champ2 > 'ABC') as B
      ON A.IdA = B.IdA

[Keihilin]

Vos deux requêtes donneront le même résultat, et ce n'est pas propre à Oracle, c'est l'écriture normalisée.

Certes.

J'aurais sûrement dû préciser que le cas rencontré n'était pas exactement celui-ci; l'exemple que je donne est juste à titre indicatif...

[Luc Orient]

Je ne sais pas si c'est à ça que tu fais allusion mais il s'agit dans cet article d'une discussion sur la différence de résultat que peut produire l'ancienne syntaxe (FROM a, b WHERE a.id = b.idA), encore trop souvent vue, par rapport à la syntaxe normalisée depuis 1992 (FROM a JOIN b ON a.id = b.idA).

Lecture très instructive qui devrait finir de vous convertir à la séparation entre condition de jointure et condition de restriction.

Pour les jointures internes, je n'ai jamais été convaincu par les arguments qui sont donnés dans l'article ( certains même gagneraient à être démontrés ou pour le moins illustrés par des exemples ). Par ailleurs je trouve ce débat particulièment surfait et inutile. L'écriture des jointures internes se fait de deux façons possibles voilà tout et pas besoin d'en faire tout un plat !

Les concepteurs du SQL d'origine n'avaient qu'à concevoir qu'une seule façon de les écrire, maintenant c'est trop tard, le mal est fait ...

[CinePhil]

Les concepteurs du SQL d'origine n'avaient qu'à concevoir qu'une seule façon de les écrire, maintenant c'est trop tard, le mal est fait ...

Il n'est pas trop tard pour se soigner !

Ecris une requête impliquant 5 ou 6 tables jointes avec des conditions de restriction sur plusieurs des tables avec les deux syntaxes. L'écriture normalisée des jointures avec JOIN est bien plus lisible, donc plus facile à déboguer que l'écriture avec WHERE.

Depuis un an que je fréquente assidûment ce forum, je ne compte plus les cas de requêtes plus ou moins complexes qui présentaient des erreurs insolubles selon leur auteur et qu'il aurait aussi aisément corrigé que moi s'il avait écrit ses jointures correctement.

[Keihilin]

Pour les jointures internes, je n'ai jamais été convaincu par les arguments qui sont donnés dans l'article ( certains même gagneraient à être démontrés ou pour le moins illustrés par des exemples ). Par ailleurs je trouve ce débat particulièment surfait et inutile.

Les débats sur les normes ne sont pas toujours très passionnants il est vrai, surtout que souvent les normes sont fixées de manière assez arbitraire.
Par contre, le fait que les deux syntaxes ne soit pas toujours interprétées de la même manière est problématique...


Peronnellement, norme ou pas norme, je favorise la syntaxe du mot-clé "JOIN" et j'applique, si possible, les restrictions de jointure à la suite du "ON".

La raison de cette préférence tient surtout à l'utilisation que je fais du SQL; il est important pour moi de pouvoir construire une requête qui représente un entrepôt d'objets sur lequel j'appliquerai des filtres dynamiquement.
De ce point de vu, j'essai dans la mesure du possible de ne pas avoir de clause "WHERE" dans cette requête.

[pacmann]

Salut !

Les concepteurs du SQL d'origine n'avaient qu'à concevoir qu'une seule façon de les écrire, maintenant c'est trop tard, le mal est fait ...

C'est pas le SQL qui permet de faire ça "sans conséquence" : c'est l'implémentation des optimiseurs...
Je veux dire par là qu'on aurait peut être pu ne jamais créer le mot "JOIN", mais on aurait quand même eu du mal à interdire le WHERE !
Pour moi, (même si fsmrel ne sera pas d'accord) le JOIN est l'opérateur de jointure, le WHERE plutot la restriction du produit cartésien...
Et la restriction du produit cartésien, c'est comme tout balancer dans un grand saladier, puis mélanger et passer à la passoire

Par ailleurs, je ne suppose que tu n'es pas convaincu qu'il est mieux d'utiliser LEFT OUTER JOIN à la place de (+) ou (*) --selon les SGBD qui pratiquent.
=> J'ai été très surpris lorsque j'ai appris qu'Oracle recommande l'écriture LEFT OUTER JOIN
(alors qu'une grande partie de la communauté ancienne préfère encore les (+))

[Luc Orient]

... Par contre, le fait que les deux syntaxes ne soit pas toujours interprétées de la même manière est problématique...

Par les jointure internes et à moins qu'on me démontre le contraire, les deux syntaxes doivent strictement donner le même résultat ... Par contre pour les jointures externes ( LEFT OUTER JOIN ), je suis d'accord que certaines différences subtiles peuvent apparaître ...

... Par ailleurs, je ne suppose que tu n'es pas convaincu qu'il est mieux d'utiliser LEFT OUTER JOIN à la place de (+) ou (*) --selon les SGBD qui pratiquent.
=> J'ai été très surpris lorsque j'ai appris qu'Oracle recommande l'écriture LEFT OUTER JOIN
(alors qu'une grande partie de la communauté ancienne préfère encore les (+))

Mais je suis d'autant plus convaincu qu'il faut utiliser le LEFT OUTER JOIN quand on en a besoin, que le SGBD que je pratique ( DB2 for z/OS ) n'a jamais implémenté cette syntaxe bizarre et pour le moins non standard ... Il n'y a pas qu'Oracle dans la vie d'un DBA ...