Deux critères simples orientent le choix entre une jointure et une sous-requête (IN, EXISTS).

Besoin des colonnes de l'autre table dans le résultat final ? Si oui, une jointure s'impose — une sous-requête ne peut renvoyer que des colonnes de la table filtrée. Si non (on veut juste savoir si une correspondance existe), une sous-requête suffit et évite d'exposer des colonnes inutiles.

Risque de doublons ? Une jointure produit une ligne par correspondance trouvée — un produit avec 2 commandes apparaît 2 fois.

SELECT p.nom FROM produits p JOIN commandes c ON p.id = c.produit_id;

Cahier, avec ses 2 commandes, apparaît 2 fois : 5 lignes au total (une par commande).

SELECT p.nom FROM produits p
WHERE EXISTS (SELECT 1 FROM commandes c WHERE c.produit_id = p.id);

Ici, chaque produit n'apparaît qu'une seule fois, quel que soit son nombre de commandes : 4 lignes (Cahier une seule fois, malgré ses 2 commandes).

À retenir :

• Une jointure est nécessaire dès que le résultat final doit afficher des colonnes de l'autre table.
• Une jointure peut dupliquer une ligne autant de fois qu'elle a de correspondances ; une sous-requête IN/EXISTS ne duplique jamais la ligne externe.
• Pour une simple question « est-ce qu'une correspondance existe ? » sans avoir besoin de ses colonnes, EXISTS est souvent plus direct et plus sûr qu'une jointure.

À vous de jouer : pour afficher la liste des produits avec, pour chacun, le nombre de ses commandes, faut-il une jointure ou une sous-requête ? Justifiez.