À quoi reconnaît-on un bon exercice SQL corrigé ?
Un bon exercice ne demande pas seulement d’écrire une syntaxe. Il présente une question métier, décrit les tables disponibles et précise le résultat attendu. La correction explique ensuite le raisonnement, les contrôles et les alternatives possibles.
Le validateur doit comparer le résultat obtenu, pas uniquement le texte de la requête. Deux solutions différentes peuvent être justes si elles retournent les bonnes colonnes, les bonnes lignes et des calculs exacts.
- Un contexte qui explique pourquoi la réponse est utile.
- Des données assez riches pour révéler les erreurs de logique.
- Des indices progressifs qui aident sans livrer immédiatement la solution.
- Une correction commentée et un contrôle du résultat.
La méthode en cinq étapes
Avant de lancer l’éditeur, écrivez en quelques mots le périmètre et la granularité attendue. Construisez ensuite la requête par blocs : source, filtres, calculs, regroupement et tri. Exécutez après chaque étape pour isoler les erreurs.
Si vous êtes bloqué, demandez d’abord un indice conceptuel. Consultez la solution seulement après une vraie tentative, puis refermez-la et réécrivez la requête sans la regarder.
- 1. Reformuler la question métier.
- 2. Identifier les tables, clés et colonnes nécessaires.
- 3. Prédire la forme du résultat.
- 4. Écrire et exécuter la requête par étapes.
- 5. Comparer, corriger, puis expliquer la solution avec vos mots.
Niveau débutant : filtrer sans perdre le sens métier
Question : affichez les commandes payées de plus de 100 €, de la plus récente à la plus ancienne. La table orders contient order_id, ordered_at, status et amount.
Commencez par sélectionner seulement les colonnes utiles. Ajoutez ensuite les deux conditions dans WHERE, puis le tri. La correction ci-dessous utilise un opérateur strict : une commande de exactement 100 € n’est pas incluse.
SELECT order_id, ordered_at, amount
FROM orders
WHERE status = 'paid'
AND amount > 100
ORDER BY ordered_at DESC;Niveau intermédiaire : agréger après une jointure
Question : trouvez les cinq clients qui ont généré le plus de chiffre d’affaires payé. Les noms se trouvent dans customers et les montants dans orders.
La jointure relie les commandes à leur client. WHERE exclut les commandes non payées avant l’agrégation. GROUP BY produit une ligne par client, puis LIMIT conserve les cinq premiers après le tri.
- Regrouper aussi par customer_id distingue deux personnes portant le même nom.
- Le filtre du statut est appliqué avant SUM.
- Une jointure vers les lignes de commande demanderait un contrôle supplémentaire des doublons.
SELECT
c.customer_id,
c.full_name,
SUM(o.amount) AS revenue
FROM customers AS c
INNER JOIN orders AS o
ON o.customer_id = c.customer_id
WHERE o.status = 'paid'
GROUP BY c.customer_id, c.full_name
ORDER BY revenue DESC
LIMIT 5;Niveau avancé : classer sans supprimer le détail
Question : classez chaque commande payée dans sa ville, de la plus élevée à la plus faible. Contrairement à GROUP BY, une fonction fenêtre conserve chaque commande dans le résultat.
DENSE_RANK attribue le même rang aux montants identiques et ne crée pas de trou après une égalité. PARTITION BY city recommence le classement pour chaque ville.
SELECT
order_id,
city,
amount,
DENSE_RANK() OVER (
PARTITION BY city
ORDER BY amount DESC
) AS city_rank
FROM orders
WHERE status = 'paid'
ORDER BY city, city_rank, order_id;Comment utiliser la correction sans perdre l’apprentissage
Une correction est utile lorsqu’elle explique pourquoi chaque clause existe et comment contrôler le résultat. Elle devient contre-productive si elle est copiée avant toute tentative ou si elle impose une seule forme de requête.
Après avoir compris une solution, modifiez une contrainte : changez le seuil, conservez les clients sans commande ou calculez un classement différent. Cette variation vérifie que le raisonnement est transférable.
- Indice 1 : identifier le concept manquant.
- Indice 2 : proposer la structure de la clause.
- Explication : relier la clause au besoin métier.
- Solution : montrer une requête vérifiée et ses limites.
Construire une progression du débutant à l’avancé
La difficulté ne doit pas venir d’un énoncé ambigu. Elle augmente lorsque l’exercice combine davantage de décisions : choisir la bonne granularité, relier plusieurs tables, gérer les valeurs NULL, comparer des périodes ou utiliser une fonction fenêtre.
Une progression cohérente revient régulièrement sur les notions précédentes dans de nouveaux contextes. Elle évite dix exercices presque identiques où seuls le nom de la table ou la valeur du filtre changent.
- Débutant : lecture, filtres, tri et calculs simples.
- Intermédiaire : agrégations, jointures, CASE et sous-requêtes.
- Avancé : CTE, fonctions fenêtre, qualité des données et optimisation.
- Projet : transformer une demande métier en analyse contrôlée.
Diagnostiquer les erreurs plutôt que recommencer au hasard
Une erreur de syntaxe empêche l’exécution ; une erreur de logique retourne un résultat faux. Commencez par lire la ligne signalée, puis réduisez la requête au plus petit bloc qui fonctionne. Pour une erreur de résultat, contrôlez le nombre de lignes à chaque jointure et le périmètre des filtres.
Conservez quelques requêtes de contrôle : nombre de commandes, somme globale, valeurs distinctes d’un statut et lignes sans correspondance. Elles permettent de vérifier rapidement une analyse plus complexe.
Choisissez votre prochain exercice
Le catalogue SQL.tn permet de filtrer les exercices par niveau et par notion. Si vous ne savez pas où commencer, le test de niveau recommande un point de départ. Le parcours Data Analyst organise ensuite la pratique autour d’indicateurs et de questions métier.