0Pricing
SQL Interview Prep · Leçon

Transformer des requêtes imbriquées en CTE

Un schéma d’entretien courant : transformer une requête imbriquée illisible en CTE successifs

Transformer des requêtes imbriquées en CTE est une leçon SQL Interview Prep gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage SQL Interview Prep, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours SQL Interview Prep comprend 4 leçons au total.

La refactorisation en entretien en direct

Un exercice classique de niveau intermédiaire : voici une requête, rendez-la lisible. L'évaluateur vous présente un SELECT profondément imbriqué et observe la manière dont vous le décomposez. Transformer l'imbrication en une suite de CTE nommées est la réponse la plus claire.

Cette leçon présente les étapes exactes afin que vous puissiez les appliquer sereinement au tableau blanc.

Commencer par la requête la plus interne

Les sous-requêtes imbriquées s'exécutent conceptuellement de l'intérieur vers l'extérieur. Lisez donc la requête de la même manière : trouvez d'abord le SELECT entre parenthèses le plus profond ; il constitue la première étape de votre chaîne de traitement.

Donnez-lui un nom descriptif et transformez-le en CTE. Tout ce qui référençait ce bloc interne référence désormais le nom de la CTE.

SELECT *
FROM (
    SELECT customer_id, SUM(amount) AS total
    FROM orders
    GROUP BY customer_id
) t
WHERE t.total > 1000;

Remonter d'un niveau dans une CTE

Prenez cette table dérivée la plus interne et transformez-la en CTE. La requête externe reste identique, à ceci près qu'elle sélectionne désormais les données de la CTE nommée.

Cette seule opération supprime déjà un niveau d'imbrication mentale et donne à l'étape un nom pertinent.

WITH spend AS (
    SELECT customer_id, SUM(amount) AS total
    FROM orders
    GROUP BY customer_id
)
SELECT *
FROM spend
WHERE total > 1000;

Un exemple véritablement imbriqué

Voici un exemple plus difficile à refactoriser : deux niveaux d'imbrication, ainsi qu'un filtre de type corrélé. L'objectif est de calculer la valeur moyenne des commandes parmi les clients appartenant à la tranche de dépenses la plus élevée.

La requête est correcte, mais difficile à lire. Nous allons la décomposer étape par étape.

SELECT AVG(o.amount) AS avg_order
FROM orders o
WHERE o.customer_id IN (
    SELECT customer_id
    FROM (
        SELECT customer_id, SUM(amount) AS total
        FROM orders
        GROUP BY customer_id
    ) s
    WHERE s.total > 1000
);

Nommer la première étape

Le bloc le plus profond calcule la dépense totale par client. Transformez-le en une CTE appelée spend. La couche intermédiaire se contente alors de filtrer cette CTE.

Remarquez que chaque extraction réduit la profondeur d'imbrication d'un niveau et ajoute un nom qui explicite le code.

WITH spend AS (
    SELECT customer_id, SUM(amount) AS total
    FROM orders
    GROUP BY customer_id
)
SELECT AVG(o.amount) AS avg_order
FROM orders o
WHERE o.customer_id IN (
    SELECT customer_id FROM spend WHERE total > 1000
);

Nommer la deuxième étape

Extrayez le filtre appliqué à spend dans sa propre CTE, big_spenders. La requête principale restante devient une jointure à plat ou un test d'appartenance sur un ensemble clairement nommé.

Chaque étape n'a désormais plus qu'une seule responsabilité, ce qui caractérise un SQL bien structuré.

WITH spend AS (
    SELECT customer_id, SUM(amount) AS total
    FROM orders GROUP BY customer_id
),
big_spenders AS (
    SELECT customer_id FROM spend WHERE total > 1000
)
SELECT AVG(o.amount) AS avg_order
FROM orders o
JOIN big_spenders b ON b.customer_id = o.customer_id;

Préserver la sémantique lors de la refactorisation

La règle d'or : une refactorisation ne doit pas modifier les résultats. Soyez attentif aux pièges qui peuvent modifier discrètement la sortie :

  • Remplacer IN par une JOIN peut introduire des lignes en double si le côté droit n'est pas distinct.
  • NOT IN avec des valeurs NULL se comporte différemment de NOT EXISTS.
  • Le niveau de granularité des agrégations doit rester identique.

Énoncez ces risques à voix haute pour montrer votre rigueur.

Vérifier la refactorisation

Comment prouver que la refactorisation est fidèle ? Mentionnez que vous exécuteriez les deux versions et compareriez le nombre de lignes et une somme de contrôle, ou que vous compareriez les jeux de résultats sur un échantillon.

Lors d'un entretien, même dire Je validerais en comparant les nombres et quelques lignes prises au hasard démontre une rigueur d'ingénierie qui va au-delà de la simple réécriture de la syntaxe.

SELECT COUNT(*), SUM(amount)
FROM orders
WHERE customer_id IN (SELECT customer_id FROM big_spenders);

Quand NOT refactoriser

La refactorisation n'est pas toujours une amélioration. Il peut être plus clair de laisser une unique sous-requête peu profonde telle quelle, et la diviser en trop nombreux petits CTE peut également nuire à la lisibilité.

Faites preuve de discernement : refactorisez lorsque l'imbrication masque l'intention ou que la logique est réutilisée. Dites à l'intervieweur que vous vous arrêteriez dès que la requête se lit de haut en bas comme une suite d'étapes distinctes et nommées.

La liste de contrôle de la refactorisation

Une méthode à réciter systématiquement :

  • Lisez de l'intérieur vers l'extérieur pour trouver la sous-requête la plus profonde.
  • Placez-la dans un CTE nommé.
  • Remontez progressivement, une couche à la fois.
  • Nommez chaque étape d'après ce qu'elle produit.
  • Vérifiez que les résultats n'ont pas changé (attention aux pièges liés à IN/JOIN et NULL).

Vous transformez ainsi une requête imbriquée inquiétante en une réécriture posée et progressive.

Présenter votre refactorisation

Présentez votre raisonnement à voix haute : Le bloc le plus imbriqué représente les dépenses par client, je l'appellerai donc dépenses. La couche suivante filtre les gros dépensiers. Puis la requête externe calcule la moyenne des montants de leurs commandes.

Les intervieweurs évaluent autant la communication que la justesse. Une refactorisation expliquée étape par étape montre précisément le niveau de maturité intermédiaire qu'ils recherchent.

Vérification rapide

Identifiez la première action correcte lors de la refactorisation d'une requête profondément imbriquée en CTE.

Récapitulatif : refactoriser en CTE

Vous avez appris une refactorisation posée et reproductible : lisez de l'intérieur vers l'extérieur, placez la sous-requête la plus profonde dans un CTE nommé, puis progressez vers l'extérieur une couche à la fois.

  • Nommez chaque étape d'après ce qu'elle produit.
  • Préservez la sémantique ; faites attention aux doublons liés à IN par rapport à JOIN et aux pièges de NULL.
  • Validez en comparant les nombres et des lignes d'un échantillon.
  • Ne divisez pas excessivement la requête ; arrêtez-vous lorsqu'elle se lit comme une suite d'étapes claires et nommées.

Le cours sur les CTE est maintenant terminé ; vous pouvez désormais refactoriser avec assurance lors d'un entretien en direct.

Questions Fréquemment Posées

La leçon « Transformer des requêtes imbriquées en CTE » est-elle gratuite ?

Oui — le texte complet de « Transformer des requêtes imbriquées en CTE » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours SQL Interview Prep, passe à CoddyKit PRO. Le cours SQL Interview Prep comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Transformer des requêtes imbriquées en CTE » ?

Un schéma d’entretien courant : transformer une requête imbriquée illisible en CTE successifs Tu pratiques SQL Interview Prep avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer SQL Interview Prep ?

Aucune expérience préalable n'est requise. SQL Interview Prep sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.

Combien de temps prend la leçon « Transformer des requêtes imbriquées en CTE » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon SQL Interview Prep ?

Oui. Chaque leçon SQL Interview Prep inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Écrire votre premier CTE
  2. Enchaîner plusieurs CTE
  3. CTE, sous-requête ou table temporaire
  4. Transformer des requêtes imbriquées en CTE
← Retour à SQL Interview Prep