RunToolz iconRunToolz
Welcome to RunToolz!
SQLBase de donnéesQualité du code

Le SQL lisible n'est pas optionnel

Comment formater les requêtes SQL pour que ton futur toi (et tes coéquipiers) ne te détestent pas.

RunToolz Team28 janvier 20263 min read

Tu hérites d'une requête. C'est une ligne. 400 caractères. Plusieurs jointures, sous-requêtes et instructions CASE toutes écrasées ensemble.

Bonne chance pour la comprendre.

Le formatage SQL n'est pas une question d'esthétique. C'est une question de si les requêtes sont maintenables.

Le problème avec le SQL dense

SELECT u.id,u.name,o.total,p.name FROM users u JOIN orders o ON u.id=o.user_id JOIN products p ON o.product_id=p.id WHERE o.created_at>'2024-01-01' AND u.status='active' ORDER BY o.total DESC;

Où est la condition de jointure ? Qu'est-ce qui est filtré ? De quelle table vient chaque colonne ?

Maintenant imagine déboguer ça à 2h du matin.

Envie d'essayer par vous-même ?Formater SQL

La même requête, lisible

SELECT
    u.id,
    u.name,
    o.total,
    p.name
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN products p ON o.product_id = p.id
WHERE o.created_at > '2024-01-01'
    AND u.status = 'active'
ORDER BY o.total DESC;

Chaque clause a sa propre ligne. Les conditions s'alignent. La structure est visible.

Règles de formatage qui fonctionnent

Une clause par ligne. SELECT, FROM, WHERE, ORDER BY ont chacun leur propre ligne.

Colonnes sur des lignes séparées. Les longues listes SELECT deviennent scannables.

Indente les conditions continues. Les conditions WHERE multiples s'alignent.

Mots-clés en majuscules. SELECT, FROM, WHERE se démarquent des noms de tables et colonnes.

Casse cohérente. Choisis un style. Tiens-t'y.

Formatage des sous-requêtes

Les sous-requêtes deviennent vite désordonnées. Indente-les clairement :

SELECT *
FROM orders
WHERE user_id IN (
    SELECT id
    FROM users
    WHERE status = 'premium'
)

Ou utilise des CTEs quand les sous-requêtes deviennent complexes :

WITH premium_users AS (
    SELECT id
    FROM users
    WHERE status = 'premium'
)
SELECT *
FROM orders
WHERE user_id IN (SELECT id FROM premium_users)

Les CTEs sont souvent plus claires que les sous-requêtes imbriquées.

Formatage des JOIN

Spécifie toujours les types de jointure. JOIN seul est INNER JOIN, mais explicite est mieux.

SELECT *
FROM orders o
INNER JOIN users u ON o.user_id = u.id
LEFT JOIN shipping s ON o.id = s.order_id

Mets la condition de jointure sur la même ligne pour les jointures simples. Passe à la ligne suivante pour les conditions complexes.

Qu'en est-il de la performance ?

Le formatage n'affecte pas l'exécution. L'optimiseur de base de données se fiche des espaces blancs.

Mais le SQL formaté est plus facile à optimiser. Tu peux voir la structure, identifier les jointures inutiles, repérer les index manquants.

Le SQL illisible cache les problèmes de performance.

Standards d'équipe

Choisis un style. Documente-le. Applique-le avec des formateurs automatisés.

Différents styles existent. Certaines équipes mettent les virgules au début des lignes. Certaines mettent tout en majuscules. D'autres non.

La cohérence compte plus que le style que tu choisis.


Chaque requête est lue plus qu'elle n'est écrite. Formate pour la lisibilité. Tes coéquipiers—et ton futur toi—te remercieront.