Le SQL, expliqué : le langage de requête qui aime se faire beau

En une phrase

Le formatage SQL est la pratique qui consiste à appliquer des règles de style cohérentes au code SQL pour le rendre plus facile à lire, à déboguer et à maintenir pour les humains.

Le problème que ça résout

Le Structured Query Language (SQL) est le roi de la manipulation de données depuis les années 70. Il a été conçu pour que les ordinateurs puissent parler aux bases de données, et il fait ça à merveille. Le hic ? Le moteur de la base de données se fiche royalement de l'apparence de votre SQL.

Pour un ordinateur, ceci :

SELECT u.id, p.profile_url, COUNT(c.id) AS comment_count FROM users u JOIN profiles p ON u.id = p.user_id LEFT JOIN comments c ON u.id = c.user_id WHERE u.signup_date > '2023-01-01' GROUP BY u.id, p.profile_url HAVING COUNT(c.id) > 5 ORDER BY comment_count DESC;

...est exactement la même chose que ceci :

select u.id,p.profile_url,count(c.id) as comment_count from users u join profiles p on u.id=p.user_id left join comments c on u.id=c.user_id where u.signup_date>'2023-01-01' group by u.id,p.profile_url having count(c.id)>5 order by comment_count desc;

Cette flexibilité est géniale pour la machine, mais c'est un véritable cauchemar pour le développeur humain. À mesure que les requêtes passent de simples recherches à des monstres complexes avec de multiples jointures et sous-requêtes, le SQL non formaté devient un mur de texte dense et illisible. Essayer de trouver un bug ou de comprendre la logique dans une requête de 100 lignes en un seul bloc, c'est la recette assurée pour une bonne migraine.

Le formatage SQL résout ce problème humain. Il impose une structure visuelle qui reflète la structure logique de la requête. En ajoutant des sauts de ligne, de l'indentation et une capitalisation cohérente, il transforme un sac de nœuds en un document clair et lisible en un coup d'œil. Il ne s'agit pas de rendre le code « joli » pour le plaisir ; il s'agit de le rendre compréhensible. C'est une courtoisie professionnelle envers vos coéquipiers et, surtout, envers votre futur vous qui devra déboguer ce code à 3 heures du matin.

Comment ça marche sous le capot

Un bon formateur SQL est bien plus qu'un simple script de recherche-remplacement. C'est un outil qui connaît le langage, qui l'analyse (le « parse ») et le comprend avant de le réécrire. Le processus se déroule généralement en trois grandes étapes.

Étape 1 : L'analyse lexicale (ou « tokenization »)

D'abord, le formateur scanne le texte brut de votre instruction SQL et le décompose en un flux de « tokens ». Un token est la plus petite unité de sens du langage. Pensez-y comme si vous décomposiez une phrase en mots individuels et en signes de ponctuation.

Pour une requête simple comme SELECT name FROM users;, le flux de tokens ressemblerait à quelque chose comme ça :

Texte du token	Type de token
`SELECT`	`KEYWORD`
`name`	`IDENTIFIER`
`FROM`	`KEYWORD`
`users`	`IDENTIFIER`
`;`	`PUNCTUATION`

L'analyseur lexical (le « lexer ») catégorise chaque morceau de l'entrée : les keywords (SELECT, FROM, WHERE), les identifiers (noms de tables et de colonnes comme users, name), les opérateurs (=, +, >), les littéraux (des chaînes de caractères comme 'admin' ou des nombres comme 42), et la ponctuation. Ce flux de tokens est la matière première pour l'étape suivante.

Étape 2 : Le parsing et l'arbre syntaxique abstrait (AST)

La liste de tokens n'est qu'une séquence plate. Pour vraiment comprendre la requête, le formateur doit en comprendre la structure grammaticale. C'est là que le parsing entre en jeu. Le parser prend le flux de tokens et construit une structure de données hiérarchique appelée Arbre Syntaxique Abstrait (Abstract Syntax Tree, ou AST).

L'AST représente la structure logique du code, un peu comme un diagramme de phrase qui montre la relation entre un sujet, un verbe et un complément.

Pour notre requête simple SELECT name FROM users;, l'AST pourrait ressembler à quelque chose comme ça, sous une forme simplifiée :

- SelectStatement
  - SelectClause
    - SelectItem
      - Identifier: "name"
  - FromClause
    - Table: "users"

Pour une requête plus complexe avec une clause WHERE, l'AST aurait une autre branche pour la WhereClause, qui contiendrait à son tour des nœuds représentant l'opérateur de comparaison et les valeurs comparées. Cet arbre est le « modèle mental » de votre requête pour le formateur. Il ne voit plus une chaîne de texte ; il voit une instruction SELECT avec des clauses et des composants spécifiques.

Étape 3 : L'affichage stylisé de l'arbre (« Pretty-Printing »)

C'est là que la magie opère. Avec l'AST en main, le formateur peut maintenant parcourir l'arbre, nœud par nœud, et le réimprimer sous forme de chaîne de caractères, mais cette fois en appliquant un ensemble de règles cohérentes.

Le « pretty-printer » a une règle pour chaque type de nœud dans l'AST :

Quand il voit un nœud SelectStatement, il sait qu'il doit commencer une nouvelle ligne.
Quand il rencontre un token KEYWORD comme SELECT, une règle détermine sa casse (par ex., UPPERCASE).
Quand il entre dans une FromClause, il sait qu'il doit afficher FROM sur une nouvelle ligne et indenter la partie suivante.
Quand il trouve une liste de colonnes dans la SelectClause, il peut avoir une règle pour mettre chaque colonne sur une nouvelle ligne si la liste dépasse une certaine longueur.
Quand il voit un token d'opérateur, il ajoute des espaces autour (= devient =).

En parcourant systématiquement l'AST et en appliquant ces règles, le formateur construit la sortie finale et propre. Cette approche est puissante car elle ne se contente pas de deviner à partir de motifs textuels. Elle comprend que user dans FROM users est un nom de table, mais que user à l'intérieur de 'user_profile.jpg' fait simplement partie d'une chaîne de caractères et ne doit pas être touché. Cela permet également aux formateurs de gérer différents dialectes SQL (par exemple, PostgreSQL, MySQL, T-SQL), car le parser peut être configuré pour comprendre la syntaxe et les keywords uniques de chacun.

Histoires vécues

Le cas de la session de débogage de minuit

Priya, une ingénieure senior, a été tirée du lit par une alerte PagerDuty : « CPU de la base de données à 99% ». Elle se connecte et trouve la source du problème : une seule et monstrueuse requête SQL qui tourne en boucle, consommant toutes les ressources. La requête avait été commitée une heure plus tôt par un dev junior. Elle a ouvert le fichier et son cœur s'est serré. C'était un bloc de 250 lignes de SQL non formaté, un méli-mélo chaotique de sous-requêtes imbriquées, d'instructions case et de multiples JOINs. Impossible de suivre la logique.

Avant même d'essayer de comprendre, elle a copié tout ce pâté de texte et l'a collé dans un formateur SQL. Instantanément, la bête a été domptée. Le résultat formaté, avec une indentation claire et des sauts de ligne, a révélé la structure de la requête. Et voilà, c'était là, gros comme une maison : un JOIN sur une table massive avec une condition ON manquante, ce qui entraînait un produit cartésien catastrophique. Elle a ajouté la clause ON correcte, a pushé le correctif et a vu le CPU de la base de données redescendre à la normale.

Leçon : Le formatage n'est pas qu'une question de style ; c'est une première étape essentielle du débogage. Il rend la structure logique visible, révélant souvent le bug au passage.

La fusion et le méli-mélo des styles

Deux startups ont fusionné, et leurs équipes d'ingénieurs ont été regroupées. L'équipe « Acme » écrivait le SQL tout en majuscules, utilisait des virgules en fin de ligne et indentait avec des tabulations. L'équipe « Bolt » utilisait des minuscules, des virgules en début de ligne et indentait avec quatre espaces. Les revues de code se sont transformées en querelles de clocher interminables et passives-agressives sur le style. « Pinaille : on utilise des keywords en minuscules ici », est devenu le commentaire le plus courant, faisant complètement dérailler les discussions sur la logique et la performance réelles.

Le nouveau tech lead, lassé de ces guerres de style, a mis en place une règle simple : tout le code SQL doit passer par un formateur automatisé dans le cadre du pipeline CI/CD avant de pouvoir être mergé. Il a configuré le formateur avec un guide de style neutre et l'a ajouté aux pre-commit hooks. Les débats ont cessé du jour au lendemain. La base de code s'est lentement uniformisée. Les ingénieurs pouvaient enfin se concentrer sur ce que le code faisait, et non sur son apparence.

Leçon : Un formateur automatisé et partagé est le pacificateur ultime. Il impose la cohérence, élimine les disputes futiles et permet aux équipes de se concentrer sur l'essentiel.

L'analyste qui ne pouvait pas copier-coller

Ben, un data analyst, devait exécuter une requête complexe pour générer un rapport de ventes trimestriel. Un ingénieur lui a envoyé la requête par e-mail. Mais quand Ben l'a copiée depuis son client de messagerie et l'a collée dans son outil de base de données, c'était le chaos. Le client e-mail avait ajouté des caractères > à chaque ligne, inséré des sauts de ligne bizarres et converti les guillemets intelligents. La requête a échoué avec une douzaine d'erreurs de syntaxe.

Frustré après dix minutes de nettoyage manuel, Ben s'est souvenu du portail d'outils internes. Il a collé tout le charabia de son e-mail — caractères > et tout le reste — dans le visualiseur SQL. L'outil a été assez malin pour ignorer les artefacts de l'e-mail, parser le SQL sous-jacent et recracher une requête parfaitement propre et exécutable. Il l'a lancée et a obtenu ses données en quelques secondes.

Leçon : Un formateur robuste est plus qu'un simple embellisseur ; c'est un outil de nettoyage qui peut sauver du code mutilé par des systèmes non prévus pour le code, comme les e-mails ou les tchats.

Erreurs et pièges courants

Ignorer les différences de dialectes. Formater une requête Microsoft T-SQL en utilisant des règles pour PostgreSQL est une mauvaise idée. Un formateur pourrait « corriger » TOP 10 en le changeant en LIMIT 10, ce qui provoquerait alors une erreur de syntaxe sur SQL Server. Assurez-vous toujours que votre formateur est configuré pour le bon dialecte SQL.
Formater du code généré. Soyez très prudent lorsque vous formatez du SQL construit dynamiquement par un programme ou un ORM (Object-Relational Mapper). Cette application peut dépendre d'une structure de chaîne de caractères très spécifique — et souvent moche. « Corriger » les espaces pourrait casser le code qui la génère ou la lit.
Débattre du style « parfait ». Le principal avantage du formatage est la cohérence. Perdre des heures à débattre pour savoir si les keywords doivent être en majuscules ou en minuscules est contre-productif. Choisissez un standard raisonnable (comme celui d'un guide de style populaire) et laissez l'outil l'imposer.
Compter sur le formatage pour corriger une mauvaise logique. Un formateur peut rendre une requête lente et inefficace magnifique. Il ne la rendra pas rapide. Le formatage rend la mauvaise logique visible, mais c'est toujours à vous de corriger les problèmes de performance ou de justesse sous-jacents.

Pourquoi vous devriez y prêter attention

Si vous travaillez avec des données, vous travaillez avec du SQL. Et si vous travaillez avec du SQL dans un cadre professionnel, sa lisibilité devrait vous importer. Vous devriez penser au formatage SQL chaque fois que vous :

Écrivez une nouvelle requête : Formatez-la avant de la commiter. C'est un cadeau pour vos collègues.
Relisez le code de quelqu'un d'autre : Si une requête est difficile à lire, votre première demande devrait être : « Peux-tu s'il te plaît la passer dans le formateur ? »
Déboguez une requête complexe : N'essayez même pas de lire le code brut. Formatez-le d'abord.
Intégrez un nouveau projet : Cherchez leur guide de style SQL ou leur configuration de formateur. C'est un moyen rapide d'apprendre les standards de l'équipe.
Démarrez un nouveau projet : Établissez un standard de formatage dès le premier jour et automatisez-le dans votre pipeline CI/CD.

En bref, le formatage n'est pas un « plus » optionnel. C'est une partie fondamentale de l'écriture de SQL professionnel, maintenable et collaboratif.

Pour aller plus loin

Wikipedia: SQL: La vue d'ensemble de haut niveau du langage lui-même.
dbt Labs SQL Style Guide: Un guide de style très respecté et pratique pour écrire du SQL dans les équipes data modernes.
Documentation de SQLFluff: La documentation d'un linter et formateur SQL populaire et hautement configurable. Sa section « Rules » est un excellent aperçu de tout ce qu'on peut configurer.
PostgreSQL: Lexical Structure: Une plongée en profondeur dans la grammaire officielle et les règles de tokenization d'un des dialectes SQL les plus populaires.