Erreurs typiques avec les sous-requêtes

Travailler avec les sous-requêtes, c’est un peu comme jouer aux échecs version strip-tease : tout paraît easy au début, jusqu’à ce que tu fasses un move foireux. Mais d’où viennent les erreurs ? D’un manque de compréhension du syntaxe, d’un oubli des subtilités de la logique SQL ou juste d’un moment d’inattention. Dans cette leçon, on va causer des erreurs les plus fréquentes et surtout comment les éviter.

Erreurs de syntaxe

Les sous-requêtes demandent d’être super attentif au syntaxe. Une virgule, une parenthèse ou un alias oublié et ton query s’effondre. Mate quelques problèmes classiques.

Parenthèses manquantes

Les parenthèses sont cruciales quand tu utilises des sous-requêtes. Une sous-requête doit toujours être entre parenthèses, et si t’en oublies une paire, c’est l’erreur de syntaxe assurée.

Exemple d’erreur :

SELECT student_name
FROM students
WHERE student_id IN SELECT student_id FROM enrollments);

Erreur :

ERROR:  syntax error at or near "SELECT"

Correction :

SELECT student_name
FROM students
WHERE student_id IN (SELECT student_id FROM enrollments);

Commentaire : La requête dans IN doit toujours être entre parenthèses pour que SQL pige que tu veux faire une sous-requête.

Alias manquant

Quand tu utilises une sous-requête dans la section FROM, pense à lui donner un alias. Sinon PostgreSQL va juste s’emmêler les pinceaux.

Exemple d’erreur :

SELECT student_name, avg_score
FROM (SELECT student_id, AVG(score) AS avg_score FROM grades GROUP BY student_id)
WHERE avg_score > 80;

Erreur :

ERROR:  subquery in FROM must have an alias

Correction :

SELECT student_name, avg_score
FROM (SELECT student_id, AVG(score) AS avg_score FROM grades GROUP BY student_id) AS subquery
WHERE avg_score > 80;

Commentaire : PostgreSQL veut que chaque table temporaire (résultat d’une sous-requête dans FROM) ait un nom.

Problèmes de performance

Les sous-requêtes, surtout mal optimisées, peuvent transformer ta base de données en escargot. Les perfs en prennent un coup à cause de calculs inutiles ou du manque d’index.

Calculs inutiles

Les sous-requêtes dans la section SELECT peuvent être recalculées pour chaque ligne du résultat, ce qui explose le temps d’exécution.

Exemple :

SELECT student_name,
       (SELECT COUNT(*) FROM enrollments WHERE enrollments.student_id = students.student_id) AS course_count
FROM students;

Si la table students a des dizaines de milliers de lignes, cette sous-requête sera exécutée à chaque ligne.

Optimisation :

WITH course_counts AS (
    SELECT student_id, COUNT(*) AS course_count
    FROM enrollments
    GROUP BY student_id
)
SELECT s.student_name, c.course_count
FROM students s
LEFT JOIN course_counts c ON s.student_id = c.student_id;

Les CTE (Common Table Expression) ou les joins permettent d’éviter de recalculer à chaque ligne. On verra ça plus en détail dans quelques niveaux :P

Manque d’index

Si tu utilises des sous-requêtes complexes dans la section WHERE, assure-toi que les colonnes nécessaires sont indexées.

Exemple :

SELECT student_name
FROM students
WHERE student_id IN (SELECT student_id FROM enrollments WHERE course_id = 10);

Si la colonne student_id dans la table enrollments n’a pas d’index, la sous-requête va faire un scan complet de la table.

Optimisation : Crée un index :

CREATE INDEX idx_enrollments_course_id ON enrollments (course_id);

Tu entends parler des index tout le temps, donc t’es sûrement déjà curieux de savoir ce que c’est. Mais attends encore quelques niveaux. Les index, c’est super important, mais c’est surtout pour accélérer les requêtes sans changer le code. Ça ne rendra pas une mauvaise requête bonne, mais ça peut booster tes requêtes en prod, surtout si t’as des tables avec des millions de lignes.

Erreurs de logique

Les erreurs de logique dans les sous-requêtes sont aussi fréquentes que les fails de syntaxe. Les soucis viennent souvent d’une mauvaise compréhension de NULL, des filtres ou des fonctions d’agrégation.

Mauvaise gestion de NULL

NULL, c’est le piège classique pour tous les débutants. Quand tu utilises IN ou NOT IN dans les sous-requêtes, la présence de NULL peut tout changer au résultat.

Exemple d’erreur :

SELECT student_name
FROM students
WHERE student_id NOT IN (SELECT student_id FROM enrollments);

Si la table enrollments contient des lignes avec student_id = NULL, la requête ne renverra rien. C’est parce que la condition NOT IN agit comme NULL IS NOT IN.

Correction :

SELECT student_name
FROM students
WHERE student_id NOT IN (SELECT student_id FROM enrollments WHERE student_id IS NOT NULL);

Filtre toujours les NULL si tu utilises NOT IN.

Erreurs dans les conditions de filtrage

Souvent, une sous-requête sert à filtrer de façon complexe, mais une erreur dans la condition peut donner un résultat complètement à côté de la plaque.

Exemple d’erreur :

SELECT student_name
FROM students
WHERE (SELECT AVG(score) FROM grades WHERE grades.student_id = students.student_id) > 80;

Si au moins un étudiant n’a pas de notes, la sous-requête renverra NULL et cet étudiant ne sera pas dans le résultat.

Correction :

SELECT student_name
FROM students
WHERE COALESCE((SELECT AVG(score) FROM grades WHERE grades.student_id = students.student_id), 0) > 80;

Utilise COALESCE pour remplacer les NULL par des valeurs par défaut.

Conseils pour éviter les erreurs

Pour éviter les erreurs classiques avec les sous-requêtes, suis ces règles :

Utilise bien les parenthèses et les alias. Si ça ne marche pas, vérifie que toutes les parenthèses sont fermées et que les alias sont bien là dans les sous-requêtes.

Optimise tes requêtes. Essaie de limiter les sous-requêtes quand tu peux utiliser JOIN, WITH ou des index.

Attention aux NULL. Pense toujours que des NULL peuvent traîner dans les sous-requêtes et utilise IS NOT NULL, COALESCE ou des trucs du genre.

Teste. Teste chaque sous-requête à part pour être sûr qu’elle renvoie ce que tu veux.

Lisibilité. Utilise des indentations et des alias pour que ton code soit lisible. Rappelle-toi : dans un mois, tu ne te souviendras peut-être plus de ce que t’as écrit.