Sous-requêtes : quand elles sont nécessaires

A retenir :

• Filtrage précis selon une valeur calculée ou une relation entre tables
• Choix entre IN, EXISTS et comparaison scalaire selon le résultat attendu
• Alias explicites pour éviter les ambiguïtés dans une requête corrélée
• Examen du plan d’exécution avant toute optimisation des requêtes

Sous-requête SQL : les situations où elle clarifie un besoin

Lorsqu’un filtre dépend d’une autre table ou d’un calcul, une sous-requête SQL exprime directement cette dépendance. Elle s’insère dans une requête principale, notamment dans la clause WHERE, la clause SELECT ou la clause FROM.

Dans la base fictive d’un magasin, l’équipe peut chercher les produits plus chers que le prix moyen. La requête interne calcule cette moyenne, puis la requête externe compare chaque prix à cette valeur unique.

Comparer une valeur à un calcul

Pour cette comparaison de données, l’opérateur supérieur convient si la sous-requête retourne une seule valeur. Selon Microsoft Learn, une sous-requête utilisée avec un opérateur de comparaison simple doit produire un résultat scalaire.

Un exemple courant consiste à sélectionner les articles dont le prix dépasse la moyenne de la table. Si la sous-requête renvoie plusieurs lignes, SQL Server signale une erreur : il faut alors envisager IN, ANY ou ALL.

Les opérateurs n’expriment pas la même règle : IN vérifie l’appartenance à une liste, tandis que ANY et ALL comparent une valeur à un ou plusieurs résultats.

Opérateurs adaptés aux résultats :

• Valeur unique : comparaison avec =, < ou >
• Liste de valeurs : IN ou NOT IN
• Au moins une valeur correspondante : ANY ou SOME
• Toutes les valeurs doivent satisfaire la condition : ALL

Filtrer sans afficher les colonnes liées

Quand la requête principale doit seulement retenir les clients ayant des commandes, EXISTS traduit clairement cette intention. La sous-requête teste la présence d’au moins une ligne correspondante sans ajouter les colonnes de commande au résultat.

Selon Microsoft Learn, EXISTS évalue si la sous-requête renvoie des lignes. Ce choix évite aussi de multiplier les lignes du client lorsqu’il possède plusieurs commandes, situation possible avec une jointure directe.

Repères pour choisir une construction :

• IN : vérifier si une valeur apparaît dans une liste
• EXISTS : tester la présence d’une ligne liée
• Jointure : afficher des colonnes issues de plusieurs tables
• Sous-requête scalaire : produire une valeur calculée dans SELECT

Besoin	Forme SQL	Résultat attendu
Prix supérieur à la moyenne	Comparaison scalaire	Une valeur calculée
Client ayant une commande	EXISTS	Test de présence
Produit d’une catégorie choisie	IN	Comparaison à une liste
Colonnes client et commande	Jointure	Champs des deux tables

Requête imbriquée : choisir son emplacement et sa portée

Une fois le besoin clarifié, l’emplacement de la requête imbriquée détermine le rôle qu’elle joue. Selon Microsoft Learn, elle peut apparaître là où une expression est autorisée, sous réserve des règles propres au contexte.

Clause WHERE, clause SELECT et clause FROM

Dans la clause WHERE, une sous-requête filtre des lignes selon un calcul ou une relation. Dans la clause SELECT, elle peut fournir une valeur calculée pour chaque ligne, à condition de retourner une seule valeur.

Dans la clause FROM, une requête dérivée sert de source intermédiaire, par exemple pour agréger les ventes par client avant de joindre ce résultat à une table de clients. Elle doit recevoir un alias dans SQL Server.

Ces emplacements répondent à des objectifs distincts : filtrer, calculer ou préparer des données. Pour une analyse en plusieurs étapes, une expression de table commune peut rendre la lecture plus confortable.

Repérer une requête corrélée

Une requête corrélée fait référence à une colonne de la requête externe. Par exemple, elle peut comparer le salaire d’un employé à la moyenne de son propre département, grâce à un identifiant partagé.

Cette dépendance est utile pour exprimer une règle par ligne, mais elle ne signifie pas automatiquement que le moteur exécute physiquement le même calcul de manière répétée. L’optimiseur choisit un plan selon la requête et les données.

Pour garder les références lisibles, attribuez un alias à chaque table et qualifiez les colonnes, surtout lorsque les tables portent des noms proches ou sont réutilisées à plusieurs niveaux.

Vérifications avant d’imbriquer :

• Résultat attendu : une valeur, une liste ou un test d’existence
• Colonnes liées : alias explicites dans chaque niveau
• Clause choisie : filtrage, calcul ou table dérivée
• Profondeur : structure encore compréhensible pour l’équipe

Emplacement	Usage courant	Point de vigilance
WHERE	Filtrer selon une autre requête	Adapter l’opérateur au nombre de résultats
SELECT	Ajouter une valeur calculée	Retourner une seule valeur par ligne
FROM	Préparer un résultat intermédiaire	Définir un alias de table
HAVING	Filtrer des groupes agrégés	Respecter la logique des agrégats

Optimisation des requêtes : vérifier avant de remplacer

Après avoir choisi une forme lisible, il reste à vérifier son comportement sur les données réelles. Une sous-requête et une jointure équivalente peuvent produire le même résultat, mais la performance dépend du plan d’exécution.

Comparer sous-requête et jointure

Si le résultat doit présenter des champs venant de plusieurs tables, une jointure est généralement plus directe. Si la demande porte seulement sur l’existence d’une relation, EXISTS peut mieux refléter l’intention et éviter les doublons produits par certaines jointures.

Dans SQL Server, certaines formulations équivalentes peuvent aboutir à des plans similaires. Il vaut donc mieux mesurer avec les outils de suivi et examiner les données, plutôt que de supposer qu’une syntaxe est toujours plus rapide.

Éviter les pièges de NULL et d’imbrication

NOT IN mérite une attention particulière si la liste retournée contient une valeur NULL : la logique SQL peut alors exclure des lignes de façon inattendue. Pour tester l’absence d’une ligne liée, NOT EXISTS exprime souvent plus sûrement l’intention.

Une imbrication profonde complique aussi le diagnostic. Exécuter séparément les blocs, vérifier leurs colonnes et utiliser des alias explicites aide à isoler une erreur avant de réintégrer la requête.

Un contrôle simple avant mise en production :

• Vérifier le résultat de chaque sous-requête isolément
• Contrôler les valeurs NULL avant d’utiliser NOT IN
• Comparer les plans d’exécution sur les données concernées
• Choisir une jointure si plusieurs tables alimentent l’affichage

Source : Microsoft Learn, « Sous-requêtes (SQL Server) », Microsoft Learn.

À retenir

Un mot qui se comprend dossier après dossier

Qu'il s'agisse de philosophie bouddhiste, de méditation, de culture tibétaine, d'industrie durable, de linguistique ou de bien-être, chaque rubrique raconte une facette différente de la même question : comment un même mot peut porter, à la fois, une pensée millénaire et un usage bien actuel. Rien n'est figé : chaque contexte nouveau peut encore faire évoluer ce sens.

Pour aller plus loin

• Comparer plusieurs sources avant de juger la portée d'une traduction ou d'une définition
• Replacer chaque terme dans son contexte culturel réel, pas seulement sa traduction littérale
• S'intéresser aux usages vivants de la langue autant qu'aux définitions figées
• Observer comment un même mot évolue d'un domaine à l'autre au fil du temps