MÉMO - Jointures SQL : implicite (WHERE) ou explicite (JOIN) ?
Depuis toujours, deux façons d'écrire une jointure SQL cohabitaient : la juxtaposition des tables dans le FROM avec la condition de rapprochement noyée dans le WHERE, ou la syntaxe dédiée avec le mot-clé JOIN.
La réforme du DCG (arrêté du 4 août 2025, applicable dès la session 2027) tranche officiellement en faveur de la seconde, en imposant le passage du SQL-89 au SQL-92.
Concrètement, il s'agit de savoir : quelle syntaxe utiliser désormais pour joindre deux tables, et comment choisir entre INNER JOIN, LEFT JOIN et RIGHT JOIN ?
Réponse rapide
| Question | Réponse |
| Norme attendue à l'examen (DCG, BTS CG) à partir de 2027 | SQL-92 : jointure explicite avec INNER JOIN / LEFT JOIN / RIGHT JOIN ... ON ... |
| Ancienne norme (SQL-89) | jointure implicite : tables séparées par une virgule dans le FROM, condition dans le WHERE — encore tolérée sur les sujets antérieurs à la réforme, à éviter en rédaction désormais |
| Jointure par défaut (aucune précision) | INNER JOIN — ne conserve que les lignes qui trouvent une correspondance dans les deux tables |
Comparatif : les trois types de jointure
| Type | Ce qu'elle renvoie | Cas d'usage typique |
| INNER JOIN | uniquement les lignes qui ont une correspondance dans les deux tables | lister les clients qui ont au moins une commande |
| LEFT JOIN | toutes les lignes de la table de gauche, avec ou sans correspondance à droite (NULL si absente) | lister tous les clients, y compris ceux qui n'ont encore jamais commandé |
| RIGHT JOIN | toutes les lignes de la table de droite, avec ou sans correspondance à gauche | symétrique du LEFT JOIN — en pratique, on préfère souvent reformuler en LEFT JOIN en inversant l'ordre des tables, pour rester cohérent d'une requête à l'autre |
Exemple d'application
Deux tables : CLIENT (codeclient, nomclient, villeclient, numcom) et COMMERCIAL (numcom, nomcommercial). On veut la liste des clients avec le nom de leur commercial.
Ancienne écriture (SQL-89, jointure implicite) — à ne plus utiliser :
|
SELECT nomclient, nomcommercial |
|
FROM CLIENT, COMMERCIAL |
|
WHERE CLIENT.numcom = COMMERCIAL.numcom; |
Écriture attendue (SQL-92, jointure explicite) :
|
SELECT nomclient, nomcommercial |
|
FROM CLIENT |
|
INNER JOIN COMMERCIAL ON CLIENT.numcom = COMMERCIAL.numcom; |
Si l'on veut aussi faire apparaître les clients qui n'ont pas encore de commercial attitré (numcom vide), on remplace INNER JOIN par LEFT JOIN : la ligne du client est alors conservée, avec NULL à la place de nomcommercial.
|
SELECT nomclient, nomcommercial |
|
FROM CLIENT |
|
LEFT JOIN COMMERCIAL ON CLIENT.numcom = COMMERCIAL.numcom; |
Erreurs fréquentes et bonnes pratiques
| Erreur | Bonne pratique |
| Continuer à écrire la jointure dans le WHERE (virgule dans le FROM) | utiliser systématiquement INNER JOIN / LEFT JOIN / RIGHT JOIN ... ON ..., seule syntaxe conforme à la norme SQL-92 attendue |
| Confondre INNER JOIN et LEFT JOIN | se demander si les lignes « sans correspondance » doivent apparaître ou non dans le résultat : oui → LEFT/RIGHT JOIN, non → INNER JOIN |
| Oublier la condition ON | sans elle, le SGBD réalise un produit cartésien (chaque ligne de la première table combinée à chaque ligne de la seconde) — un résultat aberrant, souvent démesurément long |
| Nommer deux fois la même colonne dans le SELECT sans préciser la table d'origine | préfixer la colonne par le nom (ou l'alias) de sa table dès que deux tables jointes partagent un nom de colonne (ex. numcom présent dans CLIENT et COMMERCIAL) |
En résumé
| Point clé | Réponse |
| Quelle norme utiliser à partir de la session 2027 du DCG ? | le SQL-92, avec jointures explicites (JOIN ... ON ...) |
| Quelle jointure choisir par défaut ? | INNER JOIN, sauf besoin explicite de conserver les lignes sans correspondance |
| Où placer la condition de rapprochement entre les deux tables ? | dans la clause ON, jamais dans le WHERE |
Dans la bibliothèque Rodco
Essentiel
- Les requêtes SQL
Mémo
- GROUP BY et fonctions d'agrégation SQL
- Les sous-requêtes SQL
- INSERT, UPDATE, DELETE : le langage de manipulation des données ».
