Discussion :

[shimomura22]

VOILA je lance ce post pour savoir dans quelles conditions il est préférable de choisir une sous-requête ou une jointure de table ....
Merci

[al1_24]

La réponse est : "ça dépend".
Quelle type de sous-requête ? Une table dérivée, une sous-requête corrélée ?

[shimomura22]

Si je comprend bien le choix dépend du résultat demandé ?????

[Invité]

Montrez-nous tout de suite votre requête ou un exemple, ça évitera de rester sur un stade purement théorique.

[SQLpro]

Effectivement, ça dépend....

Exemples classiques :

Code :

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

1
2
3
4
5
6
--> nom, prénom de la plus jeune personne
SELECT nom, prenom
FROM   T_PERSONNE
WHERE  date_naissance =
       (SELECT MAX(date_naissance) 
        FROM   T_PERSONNE);

Pas possible en jointure directe sans une sous requête :

Code :

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

1
2
3
4
5
SELECT nom, prenom
FROM   T_PERSONNE AS P
       INNER JOIN (SELECT MAX(date_naissance) AS date_max 
                   FROM   T_PERSONNE) AS M
             ON P.date_naissance = M.date_max;

La requête suivante donne des résultats faux :

Code :

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

1
2
3
SELECT TOP 1 nom, prenom
FROM   T_PERSONNE AS P
ORDER BY date_naissance DESC

Devinez pourquoi !

Code :

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

1
2
3
4
5
6
7
--> liste des homonymes
SELECT *
FROM   T_PERSONNE
WHERE  prenom IN (SELECT prenom
               FROM   T_PERSONNE
               GROUP  BY prenom
               HAVING COUNT(*) > 1);

On peut la remplacer par une jointure :

Code :

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

1
2
3
4
5
SELECT p1.*
FROM   T_PERSONNE AS P1
       JOIN T_PERSONNE AS P2
            ON P1.LA_CLEF <> P2.LA_CLEF
            AND P1.prenom = P2.prenom

Code :

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

1
2
3
4
5
6
7
8
--> client n'ayant pas été facturé en 2015
SELECT *
FROM   T_CLIENT AS C
WHERE  NOT EXISTS
          (SELECT 1
           FROM   T_FACTURE AS F
           WHERE  C.CLI_ID = F.CLI_ID
             AND  YEAR(FAC_DATE) = 2014);

Remplaçable par une semi anti-jointure :

Code :

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

1
2
3
4
5
6
SELECT *
FROM   T_CLIENT AS C
       LEFT OUTER JOIN T_FACTURE AS F
       ON C.CLI_ID = F.CLI_ID 
          AND YEAR(FAC_DATE) = 2014
WHERE  F.CLI_ID IS NULL;

A +

[StringBuilder]

J'aurais tendance à généraliser (même si ce n'est pas exact) que généralement :
- si la sous-requête contient une fonction d’agrégation dans la clause SELECT, alors c'est pas possible (ou plus difficile)
- sinon on peut avec une jointure plus ou moins évidente
En général :
IN/EXISTS => INNER JOIN
NOT IN/ NOT EXISTS => LEFT OUTER JOIN ... WHERE pk is NULL
HAVING COUNT(*)/SUM()... => Jointure carabinée

[SQLpro]

J'aurais tendance à généraliser (même si ce n'est pas exact) que généralement :
- si la sous-requête contient une fonction d’agrégation dans la clause SELECT, alors c'est pas possible (ou plus difficile)

Non, ce n'est JAMAIS possible.

Mais il y a deux autres cas :
1) filtrage de fonction fenêtrées
2) requêtes récursives.

A +

[Sergejack]

Effectivement, ça dépend....

La requête suivante donne des résultats faux :

Code :

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

1
2
3
SELECT TOP 1 nom, prenom
FROM   T_PERSONNE AS P
ORDER BY date_naissance DESC

Devinez pourquoi !

Parce que tu n'as pas pensé à WITH TIES. lol

Code :

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

1
2
3
4
5
6
7
--> liste des homonymes
SELECT *
FROM   T_PERSONNE
WHERE  nom IN (SELECT prenom
               FROM   T_PERSONNE
               GROUP  BY prenom
               HAVING COUNT(*) > 1);

Y a deux erreurs, là.

1) Faute de frappe (nom <> prenom)
2) Produit cartésien = probablement plus de lignes

[SQLpro]

Parce que tu n'as pas pensé à WITH TIES. lol

Donne aussi des résultats faux !

1) Faute de frappe (nom <> prenom)

Je corrige

2) Produit cartésien = probablement plus de lignes

Quel produit cartésien ? le IN est une forme de jointure....

A +

[Sergejack]

Donne aussi des résultats faux !

Comment ça pourrait être faux ?
C'est exactement le même résultat que le JOIN / MAX.

Quel produit cartésien ? le IN est une forme de jointure....

J'avais mal cité. Je faisais référence à ton

Code :

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

1
2
3
4
5
6
 
SELECT p1.*
FROM   T_PERSONNE AS P1
       JOIN T_PERSONNE AS P2
            ON P1.LA_CLEF <> P2.LA_CLEF
            AND P1.prenom = P2.prenom

[SQLpro]

Comment ça pourrait être faux ?
C'est exactement le même résultat que le JOIN / MAX.

J'avais mal cité. Je faisais référence à ton

Code :

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

1
2
3
4
5
6
 
SELECT p1.*
FROM   T_PERSONNE AS P1
       JOIN T_PERSONNE AS P2
            ON P1.LA_CLEF <> P2.LA_CLEF
            AND P1.prenom = P2.prenom

Produit cartésien c'est CROSS JOIN. Là il s'agit d'une non équi jointure, plus généralement appelé thêta jointure...
http://fr.wiktionary.org/wiki/th%C3%AAta-jointure
A +

[Sergejack]

Produit cartésien c'est CROSS JOIN. Là il s'agit d'une non équi jointure, plus généralement appelé thêta jointure...
http://fr.wiktionary.org/wiki/th%C3%AAta-jointure
A +

Tu as raison, produit cartésien n'était pas la bonne expression.
Il n’empêche que ton query est faux et peux renvoyer plusieurs fois la même lignes.


Quant à l'emploie de WITH TIES, je te laisse l'essayer puisque t'es persuadé que c'est faux sans avoir pu expliquer en quoi ^^

Code :

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

1
2
3
4
 
SELECT TOP 1 WITH TIES nom, prenom 
FROM   T_PERSONNE AS P
ORDER BY date_naissance DESC

[SQLpro]

...Quant à l'emploie de WITH TIES, je te laisse l'essayer puisque t'es persuadé que c'est faux sans avoir pu expliquer en quoi ^^

Code :

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

1
2
3
4
 
SELECT TOP 1 WITH TIES nom, prenom 
FROM   T_PERSONNE AS P
ORDER BY date_naissance DESC

Parce que la clause ORDER BY n'est pas une opération relationnelle. C'est une clause cosmétique. Elle assure le tri du résultat un fois le résultat calculé. Elle doit donc être totalement indépendante des opérations relationnelles que la requête effectue. Or si l'utilisateur veut trier le résultat sur nom, prénom, alors le résultat ne sera pas celui attendu !
Il faudrait alors faire une sous requête ce qui impliquerait deux opérations de tri dans le plan d'exécution, donc un cout exorbitant !

Toutes ces pseudo clause TOP ou LIMIT sont des fumisteries... Soit elle donnent des résultats incohérent, soient elles empêchent certaines autres opérations et au final s'avèrent plus couteuses que d'utiliser les opérateurs SQL normalisés.

A +

[Sergejack]

Je ne suis absolument pas d'accord avec cette vision du "Il ne faut pas l'utiliser où ça marche parce ailleurs ça ne marche pas".
S'il faut trier par autre chose, si il faut joindre d'autres tables, finir avec un query dont la taille en caractères est un multiple de 42, ... alors là on peut ranger l'idée au placard.

En attendant de telles conditions, ORDER BY + TOP amènent déjà SQL Server à faire bon usage des indexes.
Quand le résultat est bon* et les performances sont bonnes, faut pas tortiller du cul sous prétexte que la pratique ne rend pas d'éloge à une théorie laborieuse XD

L'essentiel est d'obtenir un résultat correct et (le plus) rapidement.

* Un résultat trié n'est pas un mauvais résultat

PS: je trouve grâve de condamner TOP + ORDER BY, t'as l'air de complètement oublié que si un tri doit être fait dans une gamme de logiciels, il faut être bête pour ne pas le faire là où des indexes le rendent rapide.