Quels concepts SQL échouent souvent en entretien Data ?

Par

Les candidats échouent fréquemment sur six concepts SQL clés en entretien, comme les fonctions fenêtre ou la gestion des NULLs. Comprendre ces notions avec exemples pratiques améliore nettement vos chances, comme le montre Nate Rosidi, expert reconnu sur KDnuggets.

3 principaux points à retenir.

  • Les fonctions fenêtre requièrent un ORDER BY précis pour un résultat fiable.
  • Les filtres avec agrégats utilisent HAVING, pas WHERE.
  • La gestion des NULLs demande COALESCE pour éviter les erreurs logiques.

Pourquoi maîtriser les fonctions fenêtre en SQL ?

Les fonctions fenêtre, ce sujet un peu mystérieux en SQL, sont pourtant essentielles quand on veut manipuler les données de manière précise. Elles semblent simples à première vue, mais je peux vous assurer que c’est souvent une vraie galère pour beaucoup, surtout lorsqu’il s’agit de bien comprendre les rôles de PARTITION BY et ORDER BY.

Commençons par l’importance de ORDER BY. Imaginez que vous essayez de trouver le deuxième achat d’un utilisateur dans les 7 jours suivant son premier achat. Vous utiliseriez probablement LAG() ou RANK(). Mais si vous ne précisez pas ORDER BY, les résultats qu’on obtient peuvent être tout sauf ce qu’on attend. Pour illustrer, regardons ce code SQL :

SELECT user_id, created_at, 
       LAG(created_at) OVER (PARTITION BY user_id ORDER BY created_at) AS previous_purchase
FROM purchases
WHERE created_at BETWEEN CURRENT_DATE - INTERVAL '7 days' AND CURRENT_DATE;

Dans cet exemple, PARTITION BY user_id assure que l’on compare les achats au sein de chaque utilisateur, tandis que ORDER BY created_at garantit que l’on traite les achats dans l’ordre chronologique. Si vous omettez ORDER BY, le système peut retourner des résultats aléatoires, rendant votre analyse complètement erronée.

Découvrez égalementQuels Docker containers pour une petite entreprise ?

Une erreur commune est justement cette omission d’ORDER BY. Pour beaucoup, les résultats semblent corrects à première vue, mais une simple inspection peut rapidement révéler le désastre que cela engendre. Tandis que des bases de données comme PostgreSQL peuvent être indulgentes, acceptant même cette omission, d’autres jusqu’à renvoyer une erreur si ORDER BY n’est pas spécifié. C’est ce qu’on appelle la cruauté de la technologie : parfois, elle vous laisse passer, d’autres fois, elle impose son propre jugement !

Dans un monde où la précision est de mise, comprendre ces subtilités est crucial. Pour approfondir encore plus ce sujet et découvrir d’autres écueils sur des fonctions SQL, jetez un œil à cette discussion sur Reddit ici. La maîtrise de ces fonctions vous permettra non seulement d’être efficace, mais aussi de briller lors des entretiens Data, ce qui est bien l’objectif, non ?

Comment filtrer correctement avec des fonctions d’agrégation ?

Quand il s’agit de filtrer des données en SQL, la distinction entre WHERE et HAVING est cruciale. Oui, ça peut paraître basique pour les pros, mais je t’assure que c’est un des points où beaucoup échouent en entretien. C’est simple : WHERE filtre les données avant toute opération d’agrégation, tandis que HAVING s’exécute après. Faisons le point sur cet aspect avec un exemple concret et un dataset de vins.

Imagine que tu as une table appelée vins, avec des colonnes nom et points. Si tu veux sélectionner uniquement les types de vins ayant une note moyenne de 90 ou plus, tu pourrais être tenté d’écrire quelque chose comme :

SELECT nom, MIN(points)
FROM vins
WHERE MIN(points) >= 90
GROUP BY nom;
Découvrez égalementQuels patrons analytiques pour le data scientist ?

Stop ! Tu viens de tomber dans le piège classique. Utiliser une fonction d’agrégation dans WHERE génère une erreur. Pourquoi ? Parce que WHERE agit avant que la fonction d’agrégation MIN() ne soit calculée. Pour corriger cela, il faut recourir à HAVING. Voici le bon usage :

SELECT nom, MIN(points)
FROM vins
GROUP BY nom
HAVING MIN(points) >= 90;

Avec ce code, tu fais d’abord le GROUP BY pour regrouper tes vins par leur nom et ensuite, tu filtreras ces groupes avec HAVING, qui peut traiter les résultats agrégés. C’est un petit subtilité mais qui pourrait bien faire la différence lors d’une question à l’oral dans une interview.

Il est fondamental de comprendre l’ordre d’exécution SQL : d’abord FROM, ensuite WHERE, puis GROUP BY, et enfin HAVING. Si tu ne maîtrises pas cela, tu risques de te retrouver à répondre à une question d’interview avec des faux pas qui te coûteront cher. Je te conseille vivement d’approfondir ces concepts, surtout si tu as des ambitions dans le domaine des données. Pour d’autres questions d’entretien, tu pourrais consulter des ressources comme ceci.

Quand et comment utiliser les self-joins efficacement ?

Le self-join, c’est un concept astucieux dans le monde des bases de données. En termes simples, il s’agit d’une opération dans laquelle une table est jointe à elle-même. Ça paraît un peu tordu, non ? Mais quand il s’agit de faire des comparaisons temporelles ou événementielles, c’est parfois indispensable. Pensez-y : si vous devez examiner les données d’un même stock à différents moments pour voir son évolution, un self-join s’impose.

Découvrez égalementQuel cours SQL gratuit avec certificat choisir pour avancer ?

Pour illustrer cela, prenons l’exemple classique du taux de change entre deux dates spécifiques, disons le 1er janvier et le 1er juillet 2020. Si toutes les données sont dans une seule table, la tentation pourrait être de recourir à des sous-requêtes corrélées. Cela peut donner des résultats, mais ne vous y trompez pas, le code devient très vite alambiqué et moins performant.

Voici comment cela se passerait avec une sous-requête corrélée :

SELECT 
    (SELECT taux FROM taux_de_change WHERE date = '2020-01-01') AS taux_janvier,
    (SELECT taux FROM taux_de_change WHERE date = '2020-07-01') AS taux_juillet,
    ((SELECT taux FROM taux_de_change WHERE date = '2020-07-01') - 
     (SELECT taux FROM taux_de_change WHERE date = '2020-01-01')) AS variation
FROM dual;

Complexe, non ? En passant au self-join, vous obtenez une solution plus élégante :

SELECT 
    t1.taux AS taux_janvier,
    t2.taux AS taux_juillet,
    (t2.taux - t1.taux) AS variation
FROM 
    taux_de_change t1
JOIN 
    taux_de_change t2 ON t1.date = '2020-01-01' AND t2.date = '2020-07-01';

Regardez comme c’est clair et concis. Le self-join vous permet de relier différentes lignes de la même table sans embrouiller le lecteur ni le compilateur. C’est comme dans un bon roman où chaque personnage a son rôle à jouer sans que les intrigues deviennent trop confuses. En entretien, la clarté et la lisibilité du code sont cruciales. Montrer que vous maîtrisez le self-join, c’est démontrer une compréhension approfondie des bases de données et des requêtes SQL.

Découvrez égalementQuelles évolutions pour la confidentialité des analytics en 2026 ?

N’oubliez pas, parfois la solution la plus simple est aussi la plus efficace. Sinon, vous risquez de vous retrouver à expliquer votre code pendant des heures, juste parce qu’une sous-requête vous semblait plus « intelligente ». Pour approfondir le concept, vous pouvez consulter des ressources supplémentaires ici.

Pourquoi préférer les CTE aux sous-requêtes imbriquées ?

Les sous-requêtes imbriquées, c’est un peu comme la mauvaise relation avec qui l’on reste trop longtemps : au début, c’est mignon, mais très vite, l’amour se transforme en déception. Combien de développeurs se sont retrouvés noyés dans le tumulte de ce type de requêtes ? Plus qu’on ne souhaiterait l’admettre. La complexité exponentielle des sous-requêtes imbriquées peut transformer un code simple en un véritable casse-tête, où pour déchiffrer les contenus, il faut une loupe et une bonne dose de patience. C’est ici qu’interviennent les Common Table Expressions (CTEs) : une bouffée d’air frais dans cet océan de confusion.

Avec leur syntaxe claire, les CTEs vous permettent d’écrire des requêtes SQL qui s’apparentent plus à une conversation fluide qu’à une énigme compliquée. Imaginez que vous devez récupérer les meilleurs acteurs par genre, selon leur fréquence d’apparition et leur note moyenne. En utilisant une sous-requête imbriquée, cela pourrait ressembler à un mille-feuille illisible de parenthèses et de joins. Mais avec les CTEs, la magie opère. 

WITH ActorFrequency AS (
    SELECT actor_id, COUNT(*) AS appearance_count, AVG(rating) AS average_rating
    FROM Movies
    GROUP BY actor_id
),
TopActors AS (
    SELECT actor_id, appearance_count, average_rating
    FROM ActorFrequency
    WHERE average_rating > 7
)
SELECT genre, actor_id, appearance_count, average_rating
FROM TopActors
JOIN Movies ON TopActors.actor_id = Movies.actor_id;

Regardez cette simplicité ! En revanche, une version avec des sous-requêtes imbriquées ressemble à ça :

SELECT genre, actor_id, 
    (SELECT COUNT(*) FROM Movies m WHERE m.actor_id = a.actor_id) AS appearance_count, 
    (SELECT AVG(rating) FROM Movies m WHERE m.actor_id = a.actor_id) AS average_rating
FROM Actors a
WHERE (SELECT AVG(rating) FROM Movies m WHERE m.actor_id = a.actor_id) > 7;
Découvrez égalementQuels outils d’analytics business pour booster votre performance ?

Le contraste est frappant. À gauche, une logique limpide, à droite, un enchevêtrement difficile à déchiffrer. Pour voir la différence de manière plus synthétique, voici un tableau qui résume :

Critère Sous-requêtes CTEs
Lisibilité Difficile à lire Claire et concise
Maintenabilité Complexe à mettre à jour Facile à modifier
Performance Peut être lente par redondance Efficace et optimisée

Il n’est pas surprenant que de nombreux experts en SQL recommandent d’opter pour les CTEs dès que cela est possible. La lisibilité et la maintenabilité du code ? Un jeu d’enfant ! N’oubliez pas, tout ce qui est confus à la première lecture ne va pas faciliter votre vie. Ne vous laissez pas piéger par les sous-requêtes imbriquées, choisissez l’élégante simplicité des CTEs.

Comment gérer les NULLs dans les requêtes SQL sans erreur ?

Lorsque vous plongez dans l’univers SQL, un des pièges les plus sournois qui attendent les développeurs est la gestion des valeurs NULL. Vous savez, cette petite malice qui se cache dans vos bases de données. Trop souvent, on entend des candidats en entretien dire que NULL est équivalent à NULL. Faux ! Dans le monde chaotique de SQL, NULL n’est pas égal à rien, même pas à lui-même. Pour le prouver, un petit rappel : si vous essayez d’évaluer une condition comme = NULL, attendez-vous à un échec retentissant. La bonne syntaxe ? Utilisez IS NULL ou IS NOT NULL.

Imaginons maintenant une situation concrète. Vous effectuez un FULL OUTER JOIN entre deux tables, disons clients et commandes. Vous pourriez vous retrouver face à des résultats inattendus. Que se passe-t-il quand une commande n’existe pas pour un client ? Les champs correspondants de la table des commandes afficheront NULL, créant ainsi un chaos dans vos résultats. Cette absence peut vous induire en erreur, surtout si vous espérez afficher un chiffre d’affaires total.

Pour remédier à cela, SQL propose une petite astuce : la fonction COALESCE. Cette fonction permet de remplacer ces valeurs NULL par une valeur par défaut. Par exemple, imaginons que vous souhaitez afficher le total des commandes, mais que certaines sont NULL. Avec COALESCE, vous pouvez facilement afficher 0 au lieu de NULL. Voici un exemple concret :

SELECT c.nom, 
       COALESCE(SUM(o.montant), 0) AS total_commandes
FROM clients c
LEFT JOIN commandes o ON c.id = o.client_id
GROUP BY c.nom;

Ce code vous permettra d’obtenir des résultats cohérents et complets, éliminant le risque d’erreur lié à des valeurs NULL. En intégrant cette logique dans vos requêtes, vous serez à mille lieux des pièges classiques qui tentent de déstabiliser vos succès en entretien.

Pour en savoir plus sur la gestion des valeurs NULL, n’hésitez pas à consulter cet article complet ici.

Quels efforts pour ne plus rater ces concepts SQL en entretien ?

Maîtriser ces six concepts SQL fréquemment ratés en entretien – fonctions fenêtre, filtres sur agrégats, self-joins, CTE, gestion des NULLs et déduplication groupée – est indispensable pour se démarquer. En intégrant ces notions avec rigueur et pratique, vous éviterez les erreurs courantes qui plombent souvent les candidats. Résultat : vos réponses gagneront en précision, lisibilité et efficacité, maximisant vos chances de succès lors des entretiens techniques.

FAQ

Quelles sont les fonctions fenêtre les plus problématiques en entretien SQL ?

Les fonctions comme LAG(), LEAD(), RANK() ou DENSE_RANK() posent souvent problème si le candidat oublie d’utiliser un ORDER BY précis au sein de la fenêtre, ce qui mène à des résultats non déterministes.

Pourquoi ne peut-on pas utiliser les fonctions d’agrégation dans WHERE ?

Parce que WHERE filtre les lignes avant l’agrégation alors que les fonctions d’agrégation s’appliquent après regroupement. Il faut utiliser HAVING pour filtrer sur des agrégats.

Quand privilégier un self-join plutôt qu’une sous-requête ?

Lorsqu’il faut comparer des lignes dans une même table sur des conditions temporelles ou événementielles, le self-join est souvent plus rapide et plus lisible que les sous-requêtes imbriquées.

Quels avantages offrent les CTE face aux sous-requêtes imbriquées ?

Les CTE permettent de structurer le code en étapes claires et réutilisables, améliorant nettement la lisibilité et la maintenabilité, contrairement aux sous-requêtes qui complexifient vite le code.

Comment éviter les problèmes liés aux NULL en SQL ?

Utiliser IS NULL / IS NOT NULL pour vérifier la présence de NULL, et remplacer les NULL indésirables par COALESCE afin d’assurer que les résultats sont complets et cohérents.

 

 

A propos de l’auteur

Franck Scandolera, expert Analytics Engineer et formateur, accompagne depuis plus de dix ans les professionnels dans la maîtrise de SQL, du data engineering et de l’automatisation. Responsable de l’agence webAnalyste et formateur en France et francophonie, il partage son savoir-faire pointu pour rendre les concepts complexes accessibles et opérationnels.

Retour en haut
Market Lift Up