Les candidats échouent souvent sur des concepts SQL essentiels en entretien, notamment les fonctions fenêtrées, la gestion des agrégats et la manipulation des NULLs. Comprendre ces notions aiguise votre stratégie pour réussir et éviter les pièges classiques.
3 principaux points à retenir.
- Les fonctions fenêtrées sans ordre défini produisent des résultats erratiques.
- La clause HAVING filtre après agrégation, contrairement à WHERE.
- Gérer les NULLs avec COALESCE évite les résultats inattendus.
Pourquoi les fonctions fenêtrées posent problème en entretien
Les fonctions fenêtrées, ou window functions, c’est un peu le vilain petit canard des entretiens data. Pourquoi ? Parce qu’elles exigent une compréhension fine du partitionnement et de l’ordre. Quand un candidat entend « LAG() » ou « LEAD() », il est souvent pris de court, comme s’il venait de voir un plat étrange sur un menu : « Ça doit être bon, mais je n’en ai jamais entendu parler ! » L’erreur commune ? Oublier l’ORDER BY.
Imaginez que vous voulez comparer les revenus d’une entreprise d’un trimestre à l’autre. Vous utilisez LAG() pour obtenir le revenu du trimestre précédent. Si vous ne spécifiez pas d’ordre, c’est une recette pour le désastre. Le code ci-dessous illustre la différence :
SELECT trimestre, revenu,
LAG(revenu) OVER () AS revenu_precedent
FROM revenus_trimestriels;
Sans ORDER BY, il ne saura pas dans quel ordre traiter les trimestriels, ce qui peut donner des résultats erronés. En revanche, avec l’ORDER BY, c’est le jour et la nuit :
SELECT trimestre, revenu,
LAG(revenu) OVER (ORDER BY trimestre) AS revenu_precedent
FROM revenus_trimestriels;
Maintenant, le LAG() fonctionne comme un chef d’orchestre : tout est clair, chaque trimestre s’aligne correctement. Et là, la magie opère !
Pour bien maîtriser ces fonctions, il est également important de comprendre la différence entre les agrégats classiques et les fonctions fenêtrées. Les agrégats, comme SUM() ou COUNT(), traitent l’ensemble des lignes et retournent une seule valeur. En revanche, les fonctions fenêtrées calculent des valeurs pour chaque ligne tout en respectant le cadre établi par la clause PARTITION BY et l’ORDER BY.
- Les agrégats : une vue d’ensemble, perdent en granularité.
- Les fonctions fenêtrées : précision et clarté avec un coup d’œil sur les tendances.
En fin de compte, un entretien est un lieu d’échange et de compréhension. Ce n’est pas qu’une question de tester des connaissances, mais d’appeler à l’ingéniosité. Si vous maîtrisez les fenêtres, vous aurez une longueur d’avance – pressez-vous de leur ouvrir la vôtre ! Pour plus de conseils sur les entretiens techniques, consultez cet article enrichissant.
Comment filtrer correctement avec GROUP BY HAVING et WHERE
Quand on parle de SQL, il y a un duo qui semble souvent être en désaccord : WHERE et HAVING. La grande question : quel est leur rôle respectif et surtout, pourquoi est-ce crucial de les distinguer lors des entretiens ? Laissez-moi vous éclairer avec une simple analogie : imaginez que WHERE soit votre filtre à café et HAVING, le moment où vous savourez le breuvage. Vous filtrez avant de déguster, et cette logique s’applique également à SQL.
La première chose à comprendre, c’est l’ordre d’exécution. En SQL, il est clair et bien défini. WHERE opère en premier, avant toute agrégation des données. Cela signifie qu’il réduit la noix de données à une petite quantité avant de passer à l’agrégation. En revanche, HAVING fonctionne après cette étape, uniquement sur les résultats agrégés. À ce stade, vous pouvez appliquer des conditions sur les résultats comme MIN(), AVG(), et autres fonctions d’agrégat.
Prenons un exemple courant pour illustrer cela. Imaginez une table étudiants avec une colonne points et que vous souhaitiez trouver tous les groupes d’étudiants ayant un score minimum de 90 :
SELECT classe, MIN(points)
FROM etudiants
WHERE MIN(points) >= 90
GROUP BY classe;Cette requête, mes amis, va générer une erreur. Pourquoi ? Parce que MIN(points) n’est pas encore disponible lors de l’exécution de WHERE. La solution, c’est d’utiliser HAVING :
SELECT classe, MIN(points)
FROM etudiants
GROUP BY classe
HAVING MIN(points) >= 90;Voilà, le problème est corrigé. En entretien, comprendre cette nuance est crucial. Les recruteurs ne cherchent pas seulement des réponses correctes, mais ils évaluent votre capacité à réfléchir logiquement et à comprendre la mécanique SQL.
En fin de compte, être conscient de l’ordre d’exécution et des rôles distincts de WHERE et HAVING peut vous éviter des trappes en entretien, où chaque détail compte. Pour approfondir ce sujet fascinant, je vous recommande vivement de jeter un œil à cet article riche en informations. Vous n’en sortirez que plus armé !
Pourquoi préférer les self-joins aux sous-requêtes complexes
Dans le monde de SQL, le self-join est souvent perçu comme un super-héros méconnu, préférant rester dans l’ombre de ses cousins plus bruyants, comme les sous-requêtes. Pourtant, il mérite d’être à l’avant-scène, surtout lorsqu’il s’agit de comparer des lignes d’une même table selon des critères temporels ou d’événements. La force du self-join réside dans sa simplicité et son efficacité, alors que les sous-requêtes peuvent rapidement se transformer en labyrinthes obscurs.
Prenons un exemple concret sur l’évolution d’un taux de change entre deux dates. Supposons que nous avons une table appelée changements qui contient les colonnes date et taux :
CREATE TABLE changements (
date DATE,
taux DECIMAL(10, 4)
);
Imaginons que nous voulons comparer les taux de change de deux dates spécifiques. D’abord, regardons la solution avec une sous-requête corrélée :
SELECT a.date, a.taux,
(SELECT b.taux FROM changements b WHERE b.date = DATEADD(day, -1, a.date)) AS taux_precedent
FROM changements a
WHERE a.date = '2023-10-10';
C’est déjà un peu tortueux, n’est-ce pas ? La lenteur et la complexité de cette requête se font immédiatement ressentir, surtout avec de gros volumes de données. Maintenant, optons pour une méthode plus élégante avec un self-join :
SELECT a.date, a.taux, b.taux AS taux_precedent
FROM changements a
JOIN changements b ON a.date = DATEADD(day, 1, b.date)
WHERE a.date = '2023-10-10';
Cette solution avec self-join est non seulement plus lisible, mais elle améliore aussi les performances. Elle supprime le besoin d’une requête imbriquée, qui, avouons-le, pourrait faire perdre la tête à n’importe quel analyste de données !
Voici un tableau comparatif :
| Critères | Sous-requête corrélée | Self-join |
|---|---|---|
| Lisibilité | Complexe | Clair |
| Performance | Assez lent | Rapide |
| Simplicité | Tortueuse | Élégante |
Adopter le self-join, c’est opter pour la simplicité tout en mainteneant l’efficacité. Pour davantage de détails sur les sous-requêtes, n’hésitez pas à consulter cet article ici. Rappelez-vous, en data, chaque seconde compte, et choisir les bonnes méthodes peut faire toute la différence.
Quand utiliser CTE plutôt que subqueries pour la clarté
Tu as déjà essayé de déchiffrer une requête SQL où les sous-requêtes se bousculent comme un embouteillage en heure de pointe ? C’est le cauchemar des analystes et des développeurs. Les sous-requêtes imbriquées peuvent vite devenir un vrai labyrinthe de logique. Si tu commences à creuser, tu te retrouves avec des niveaux de complexité qui dépassent l’entendement. Et puis, comment maintenir ce genre de code ? Bienvenue en enfer !
Les limites des sous-requêtes sont claires : tu perds rapidement toute lisibilité. Avec des répétitions de logique, tu rends la maintenance non seulement difficile, mais presque impossible. La plupart des interviewer te diront que le code doit être non seulement fonctionnel, mais aussi compréhensible. Quand on voit des sous-requêtes imbriquées, la règle semble oubliée.
C’est là qu’interviennent les Common Table Expressions, ou CTE. Les CTE te permettent de décomposer la logique en étapes claires et nommées. Elles sont faciles à lire et à maintenir. Imagine que tu devais calculer toute une série d’agrégats sur une table complexe. Une CTE te permettrait de faire ça comme dans un livre ouvert, plutôt que de jongler avec des parenthèses et des sous-requêtes.
Pour te donner un exemple concret, prenons une situation d’entretien classique. Supposons que l’on veut récupérer la somme des ventes par catégorie et par période.
WITH CategorySales AS (
SELECT CategoryID, SUM(SalesAmount) as TotalSales
FROM Sales
GROUP BY CategoryID
),
PeriodSales AS (
SELECT SaleDate, SUM(SalesAmount) as DailySales
FROM Sales
GROUP BY SaleDate
)
SELECT cs.CategoryID, ps.SaleDate, cs.TotalSales, ps.DailySales
FROM CategorySales cs
JOIN PeriodSales ps ON cs.SaleDate = ps.SaleDate;
En contraste, voici ce qu’une requête avec des sous-requêtes imbriquées donnerait :
SELECT CategoryID,
(SELECT SUM(SalesAmount)
FROM Sales AS s1
WHERE s1.CategoryID = s.CategoryID) AS TotalSales,
(SELECT SUM(SalesAmount)
FROM Sales AS s2
WHERE s2.SaleDate = '2023-01-01') AS DailySales
FROM Sales s
GROUP BY CategoryID;
Voilà le résultat : la première version est claire, lisible, et t’offre des références pour des modifications futures, tandis que la seconde est une véritable torture pour l’esprit. Entre maintenance et compréhension, il n’y a pas photo. Pour gagner la bataille des codes en entretien, n’oublie pas d’évoquer les CTE et leur pouvoir déchiffreur. Souviens-toi, la clarté est reine, et les CTE, ses fidèles serviteurs. Pour approfondir davantage sur ce sujet, tu peux consulter cet article.
Comment gérer proprement les NULLs en SQL
Les NULLs en SQL, un véritable casse-tête pour un bon nombre de data analysts. Premièrement, il est essentiel de saisir que NULL n’est pas une valeur. C’est un état d’indétermination, une absence d’information. Vous devez donc vous méfier, car NULL ne se compare **jamais** avec un ‘=’. Un grand classique, c’est d’essayer de vérifier si une colonne vaut NULL avec un simple opérateur d’égalité. Spoiler alert : ça ne marche pas. Pour ce faire, il faut utiliser la condition IS NULL. Car oui, en SQL, la logique du NULL bouscule un peu nos certitudes.
Imaginez un scénario : vous réalisez une jointure entre deux tables, disons clients et commandes. Vous mettez en place un FULL OUTER JOIN pour récupérer toutes les informations, même celles qui pourraient manquer. Le résultat ? Vous vous retrouvez avec des lignes où les valeurs sont NULL, car certaines commandes ne sont associées à aucun client. Cela peut donner lieu à des résultats aussi déroutants que: “Pourquoi diable mes totaux sont-ils faux ?” Si vous laissez un NULL dans un calcul, il va entraîner des résultats inattendus ou tout simplement absents. Vous avez un problème, vous le saviez déjà ?
Heureusement, il existe une solution : COALESCE. Cette fonction permet de remplacer les NULL par une valeur par défaut pertinente. Que ce soit 0 pour un total ou une chaîne vide pour une donnée textuelle, elle peut réellement transformer des résultats erronés en données exploitables. Par exemple, vous pouvez appliquer COALESCE comme ceci :
SELECT clients.nom, COALESCE(commandes.total, 0) AS total
FROM clients
FULL OUTER JOIN commandes ON clients.id = commandes.client_id;Avec cette simple ligne, vous assurez que pour chaque client, même s’il a commandé zéro, vous avez une entrée, plutôt qu’un NULL troublant vos analyses. Bien maîtriser la gestion des NULLs donne non seulement un coup de pouce à la précision de vos requêtes, mais ça montre aussi votre compréhension de la logique SQL. En conclusion, l’importance d’une gestion soignée des NULLs ne saurait être trop soulignée, surtout dans le monde des données où chaque chiffre compte. Pour approfondir le sujet, vous pouvez consulter cet article sur les NULLs en SQL ici.
Prêt à maîtriser ces concepts SQL pour vos entretiens data ?
Les entretiens SQL ne laissent pas de place aux approximations. Les six concepts évoqués — fonctions fenêtrées, clauses HAVING versus WHERE, self-joins, CTE versus subqueries, gestion des NULLs, et déduplication groupée — sont fondamentaux et souvent mal compris. Les maîtriser augmente drastiquement vos chances de succès. En intégrant ces bonnes pratiques, vous gagnerez en confiance et en efficacité, et éviterez les pièges classiques qui éliminent souvent les bons profils. Votre préparation SQL sera enfin solide, claire et performante.
FAQ
Pourquoi ORDER BY est-il indispensable dans les fonctions fenêtrées ?
Quelle est la différence entre WHERE et HAVING ?
Quand utiliser un self-join plutôt qu’une sous-requête ?
Pourquoi privilégier les CTE aux sous-requêtes imbriquées ?
Comment gérer les NULLs pour éviter les erreurs de logique ?
A propos de l’auteur
Franck Scandolera, expert Analytics Engineer et formateur depuis plus de 10 ans, intervient dans toute la francophonie sur les sujets data, automatisation et SQL. Responsable de l’agence webAnalyste et de Formations Analytics, il accompagne agences et entreprises dans la maîtrise des outils clés (GA4, BigQuery, SQL) et la mise en œuvre de pipelines data fiables, conformes et orientés usages métiers. Son approche pragmatique garantit des formations accessibles et adaptées aux besoins opérationnels.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GTM server, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.