Bonnes pratiques SQL : des requêtes lisibles et maintenables

Leçon 10.1 · Temps de lecture : ~8 min

Les bonnes pratiques SQL sont les habitudes de mise en forme et de nommage qui rendent une requête facile à lire, à relire et à modifier. Dans cette leçon, vous apprendrez à disposer les clauses et les colonnes, à nommer tables, colonnes et alias, quand les commentaires aident, quelles habitudes évitent les bugs, et comment transformer une requête sur une ligne en code que votre équipe peut maintenir.

Dans le module précédent, vous avez travaillé avec des vues et des tables temporaires, et vos requêtes ont grandi jusqu'à de nombreuses jointures et plusieurs étapes. À cette taille, la qualité du code compte autant que l'exactitude : le SQL est lu bien plus souvent qu'il n'est écrit, par vos collègues en revue et par vous-même quelques semaines plus tard.

Un code bien structuré rend les bugs visibles, accélère les revues et facilite l'évolution des requêtes. Aucune de ces règles ne change ce que fait la base de données ; elles changent la vitesse à laquelle une personne comprend la requête.

Pourquoi le style de code compte

Une requête de 5 à 10 lignes se comprend d'un coup d'œil. Un rapport avec de nombreux JOIN, sous-requêtes ou CTE, non ; un style cohérent vous aide à :

• Trouver les bugs plus vite : un mauvais filtre ou une condition de jointure manquante saute aux yeux dans un code propre.
• Faire évoluer les requêtes sans risque : une nouvelle colonne ou condition a une place évidente.
• Travailler en équipe : tout le monde lit le code dans la même disposition, et les revues portent sur la logique plutôt que sur le style.

Mise en forme et indentation

SQL ignore les espaces et la casse des mots-clés : la disposition dépend donc de vous. Voici les conventions les plus répandues.

Mots-clés en majuscules

Écrivez les mots-clés SQL (SELECT, FROM, WHERE, JOIN, GROUP BY) en majuscules et les noms en minuscules. La structure de la requête se détache alors des données qu'elle utilise.

-- Difficile à parcourir
select title, rental_rate from film where rating = 'G';

-- Plus facile à parcourir
SELECT title, rental_rate
FROM film
WHERE rating = 'G';

Résultat : les deux requêtes renvoient les mêmes 178 films ; seule la disposition diffère.

Une clause par ligne

Commencez chaque clause principale sur une nouvelle ligne. Quand SELECT ou GROUP BY liste beaucoup de colonnes, placez-en une par ligne, indentée :

SELECT
    customer_id,
    first_name,
    last_name,
    email
FROM customer
WHERE active = 1
ORDER BY last_name;

Avec une colonne par ligne, ajouter ou supprimer une colonne modifie une seule ligne, et le diff de la revue montre exactement cette ligne.

Conventions de nommage

Minuscules et snake_case

Le standard de fait, ce sont des noms en minuscules avec des underscores entre les mots : customer_orders, total_amount, et non CustomerOrders ou TotalAmount. Les bases traitent la casse des identifiants différemment : PostgreSQL convertit les noms non entre guillemets en minuscules, et MySQL sous Linux distingue la casse des noms de tables. Le snake_case évite ces surprises.

Des préfixes cohérents

Certaines équipes marquent le type d'objet par un préfixe, comme v_ pour les vues (v_active_customers) et tmp_ pour les tables temporaires (tmp_monthly_report). Sakila n'utilise pas de préfixes : ses vues s'appellent customer_list, film_list, sales_by_film_category. Les deux approches fonctionnent ; l'important est de choisir une seule règle pour toute la base.

SELECT category, total_sales
FROM sales_by_film_category
ORDER BY total_sales DESC
LIMIT 3;

Résultat : les trois catégories aux ventes les plus élevées : Sports, Sci-Fi et Animation.

Des alias clairs

Alias de tables

Utilisez des alias courts mais parlants, comme les premières lettres du nom de la table. Des alias comme t1, t2, a, b obligent le lecteur à chercher ce que chacun signifie :

-- Peu clair : que sont t1 et t2 ?
SELECT t1.first_name, t2.amount
FROM customer t1
JOIN payment t2 ON t1.customer_id = t2.customer_id;

-- Clair
SELECT c.first_name, p.amount
FROM customer c
JOIN payment p ON c.customer_id = p.customer_id;

Noms des colonnes calculées

Donnez un nom à chaque agrégat et à chaque expression avec AS. Une colonne de rapport nommée COUNT(*) est difficile à utiliser dans une application ou un tableur :

SELECT
    c.name AS category_name,
    COUNT(*) AS film_count,
    AVG(f.replacement_cost) AS avg_replacement_cost
FROM film f
JOIN film_category fc ON f.film_id = fc.film_id
JOIN category c ON fc.category_id = c.category_id
GROUP BY c.name
ORDER BY film_count DESC;

Résultat : 16 catégories avec des noms de colonnes clairs ; Sports compte le plus de films, 74.

Commentaires

Les commentaires expliquent pourquoi le code fait quelque chose quand la raison n'est pas évidente à la lecture : une règle métier, un filtre inhabituel, un problème connu dans les données.

• Les commentaires sur une ligne (--) expliquent un filtre ou une formule.
• Les commentaires de bloc (/* ... */) décrivent le but d'un script.

/*
  Rapport : dépenses des clients en juillet 2005
  Utilisé par : la newsletter marketing mensuelle
*/
SELECT
    customer_id,
    SUM(amount) AS july_spent
FROM payment
WHERE payment_date >= '2005-07-01'  -- tout le mois,
  AND payment_date < '2005-08-01'   -- y compris le 31 juillet après minuit
GROUP BY customer_id
ORDER BY july_spent DESC;

Résultat : 599 clients avec leurs dépenses de juillet 2005.

Ne commentez pas ce que le code dit déjà : -- sélectionne customer id au-dessus de SELECT customer_id n'ajoute que du bruit, et des commentaires périmés sont pires que pas de commentaires du tout.

Des habitudes qui rendent les requêtes plus sûres

• Listez les colonnes nécessaires au lieu de SELECT * dans les rapports, les vues et le code applicatif. Une nouvelle colonne dans la table ne pourra alors ni changer ni ralentir votre résultat.
• Utilisez un JOIN ... ON explicite plutôt que de lister les tables séparées par des virgules dans FROM. La condition de jointure reste à côté de la table et s'oublie plus difficilement.
• Préférez les intervalles de dates semi-ouverts (>= début AND < fin) à BETWEEN pour les colonnes date-heure, comme dans l'exemple ci-dessus.
• Convenez d'un style et automatisez-le. Les outils de formatage et les linters comme SQLFluff appliquent les règles pour vous, et les revues ne débattent plus des espaces.

Exemple pratique : nettoyer une requête désordonnée

Avant : tout sur une ligne, pas de noms pour les colonnes calculées :

select f.title,c.name,count(r.rental_id) from film f join film_category fc on f.film_id=fc.film_id join category c on fc.category_id=c.category_id join inventory i on f.film_id=i.film_id join rental r on i.inventory_id=r.inventory_id group by f.title,c.name having count(r.rental_id)>30 order by count(r.rental_id) desc;

Après : une clause par ligne, jointures alignées, colonnes nommées :

SELECT
    f.title,
    c.name AS category_name,
    COUNT(r.rental_id) AS rental_count
FROM film f
JOIN film_category fc ON f.film_id = fc.film_id
JOIN category c       ON fc.category_id = c.category_id
JOIN inventory i      ON f.film_id = i.film_id
JOIN rental r         ON i.inventory_id = r.inventory_id
GROUP BY f.title, c.name
HAVING COUNT(r.rental_id) > 30
ORDER BY rental_count DESC;

Résultat : les deux versions renvoient les mêmes 16 films loués plus de 30 fois, avec en tête BUCKET BROTHERHOOD et ses 34 locations.

Dans la seconde version, on voit d'un coup d'œil quelles tables sont jointes et comment, ce qui est compté, et comment le résultat est filtré et trié.

Points clés :

• Écrivez les mots-clés en majuscules et les noms en minuscules, en snake_case.
• Commencez chaque clause sur une nouvelle ligne et écrivez les longues listes de colonnes une par ligne.
• Utilisez des alias de tables parlants et nommez chaque colonne calculée avec AS.
• Commentez le pourquoi, pas le quoi : règles métier et filtres non évidents.
• Listez les colonnes au lieu de SELECT *, utilisez un JOIN ... ON explicite et des intervalles de dates semi-ouverts.
• Convenez d'un style unique en équipe et appliquez-le avec un outil de formatage ou un linter.

Questions fréquentes

Les mots-clés SQL doivent-ils être en majuscules ?

Non. Les bases acceptent les mots-clés dans n'importe quelle casse. Les majuscules sont une convention qui rend la structure des longues requêtes plus visible ; le plus important est que toute l'équipe utilise le même style.

Qu'est-ce qui rend du code SQL maintenable ?

Une mise en forme cohérente, des noms et alias clairs, des colonnes calculées nommées et de courts commentaires là où la logique n'est pas évidente. Un tel code est plus facile à relire, à modifier et à déboguer, y compris par ceux qui ne l'ont pas écrit.

Pourquoi éviter SELECT * dans les requêtes de production ?

SELECT * renvoie toutes les colonnes, y compris celles ajoutées plus tard à la table. Cela peut casser les applications qui attendent un ensemble fixe de colonnes, transférer plus de données que nécessaire et empêcher l'utilisation d'index couvrants. Listez les colonnes dont vous avez besoin.

Comment nettoyer une requête SQL désordonnée ?

Découpez-la en clauses sur des lignes séparées (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY), indentez les listes de colonnes, remplacez les alias peu clairs, nommez les colonnes calculées et ajoutez un commentaire là où la logique mérite une explication. Exécutez l'ancienne et la nouvelle version pour vérifier que les résultats sont identiques.