CodeGym /Cours /SQL SELF /Erreurs typiques lors de l'utilisation de SELECT

Erreurs typiques lors de l'utilisation de SELECT

SQL SELF
Niveau 3 , Leçon 3
Disponible

Comme dans n'importe quel autre domaine du dev, avec SELECT les erreurs sont inévitables. Même les devs SQL les plus expérimentés laissent parfois des bugs dans leurs requêtes. Aujourd'hui, on va décortiquer les erreurs typiques avec SELECT, pourquoi elles arrivent et comment les éviter.

SQL, c'est un langage qui ne rigole pas avec la syntaxe. Une virgule oubliée ou en trop, un mot-clé manquant ou l'ordre des mots pas bon – et la base de données lève direct un "drapeau rouge".

Mots-clés oubliés

L'erreur la plus fréquente, c'est juste d'oublier un mot-clé obligatoire. Par exemple, essayons cette commande :

SELECT name age FROM students;

Il manque un truc, non ? Ici, il manque la virgule , entre les champs name et age. On corrige :

SELECT name, age FROM students;

La raison de ce genre d'erreur est claire : soit tu débutes en SQL, soit tu vas trop vite. SQL n'aime pas la précipitation !

Erreurs dans les noms de colonnes et de tables

Les commandes SQL sont sensibles aux bons noms de colonnes et de tables. Essayons cette requête :

SELECT naem, agge FROM studnts;

La base de données voit ça comme du charabia : les colonnes naem et agge, tout comme la table studnts, n'existent tout simplement pas. On corrige :

SELECT name, age FROM students;

Astuce : Si t'es pas sûr des noms, utilise la commande \d table_name dans psql ou l'interface pgAdmin pour checker la structure de la table.

Guillemets oubliés

Les noms de colonnes et de tables qui contiennent des espaces ou des caractères spéciaux doivent être entourés de guillemets doubles. Exemple :

SELECT "first name", age FROM students;

Si tu oublies les guillemets, SQL ne va rien comprendre et va te sortir une erreur.

Erreurs logiques : quand tout marche, mais pas comme tu voulais

Parfois, les requêtes s'exécutent sans souci, mais le résultat est "chelou". Ce sont des erreurs logiques. Elles sont plus vicieuses, parce que la base de données ne te dira pas qu'il y a un souci.

  1. Mauvaise utilisation des opérateurs de comparaison. Imagine que tu veux sélectionner tous les étudiants de plus de 18 ans :
SELECT * FROM students WHERE age > 18;

Maintenant, essayons une requête avec un autre opérateur :

SELECT * FROM students WHERE age = 18;

Cette requête va retourner seulement ceux qui ont exactement 18 ans. Si tu voulais tous ceux de plus de 18, c'est une erreur logique.

Astuce : Fais gaffe à ce genre de détails. Si t'as un doute, commence par des petits échantillons (genre avec LIMIT).

Erreurs en combinant les conditions

Regarde cet exemple :

SELECT * FROM students WHERE age > 18 OR grade = 'A' AND city = 'New York';

Cette requête peut te ramener des étudiants qui n'habitent pas à New York. Pourquoi ? Parce que l'ordre des opérateurs logiques est comme ça : SQL traite d'abord AND, puis OR. On réécrit la requête avec des parenthèses :

SELECT * FROM students WHERE (age > 18 OR grade = 'A') AND city = 'New York';

Maintenant c'est bon.

Pas de filtrage

Parfois, une requête comme SELECT * FROM students; te sort une tonne de données, alors que tu voulais juste les étudiants d'une ville précise. La solution ? Ajoute des filtres avec WHERE :

SELECT * FROM students WHERE city = 'New York';

Problèmes de performance

Quand les requêtes bossent sur beaucoup de données, c'est super important de les optimiser. Voyons les erreurs classiques qui plombent la perf.

Les requêtes du genre SELECT * sont pratiques en dev, mais en prod, ça flingue la perf. Si t'as besoin que de certaines colonnes – précise-les.

-- Pas top :
SELECT * FROM students;

-- Mieux :
SELECT name, age FROM students;

Pourquoi c'est important ? SELECT * récupère toutes les colonnes, même celles dont tu te sers pas. Ça fait plus de données à transférer.

Conseils pratiques : comment éviter les erreurs

Tu peux rendre tes requêtes SQL plus fiables en suivant quelques tips :

  • Vérifie la syntaxe avant d'exécuter : utilise une IDE ou les suggestions de pgAdmin, ça peut te pointer les erreurs à l'avance.
  • Commence par des petits échantillons. Ajoute LIMIT 5 ou LIMIT 10 pour tester.
  • Utilise des commentaires pour comprendre ce que fait la requête :
    -- Sélectionner tous les étudiants de plus de 18 ans
    SELECT name, age FROM students WHERE age > 18;
    
  • Teste avec différentes données pour vérifier que ta logique tient la route.
  • N'abuse pas de SELECT *, surtout sur les grosses tables.

Pièges en entretien

Un des exercices classiques en entretien SQL, c'est de trouver les erreurs dans une requête. Par exemple :

SELECT name FROM employees WHERE salary > 50000 ORDER BY department;

Demande-toi : est-ce que cette requête est logique ? Si on utilise ORDER BY, c'est sûrement pour trier par salaire :

SELECT name FROM employees WHERE salary > 50000 ORDER BY salary DESC;

Bosser avec SELECT, c'est la base de SQL, et les erreurs sont inévitables au début. Mais avec le temps, tu vas écrire des requêtes aussi facilement que tu tapes des messages sur WhatsApp, parce que les vrais devs s'entraînent pas que sur les chats, mais aussi sur les bases de données. 😉

1
Étude/Quiz
Tri des données, niveau 3, leçon 3
Indisponible
Tri des données
Tri des données
Commentaires
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION