Comment formater des requêtes SQL

Le SQL desordonne est l'un des moyens les plus rapides d'introduire des bogues. Lorsqu'une requete est une seule longue ligne sans indentation, il est difficile de voir quelles conditions s'appliquent a quelles jointures, ou commencent et se terminent les sous-requetes, ou si la logique est correcte. Un formateur base sur navigateur gere tout le travail localement sans televerser vos requetes sur un serveur.

Pourquoi le formatage est important

• Debogage : une requete bien formatee rend les erreurs de logique visibles. Vous pouvez tracer le flux de SELECT a WHERE a JOIN sans deviner.
• Revue de code : les reviseurs peuvent lire du SQL formate en quelques secondes. Une requete sur une seule ligne les force a la parcourir mentalement d'abord.
• Maintenance : lorsque vous revisez une requete des mois plus tard, le formatage vous dit ce qu'elle fait d'un coup d'oeil.
• Collaboration : un formatage coherent dans une equipe signifie que tout le monde lit le SQL de la meme facon.
• Integration : les nouveaux membres de l'equipe peuvent lire du SQL formate sans avoir besoin de l'histoire orale de chaque requete.
• Documentation : lorsque le SQL apparait dans les documents de conception, runbooks ou wikis, les requetes formatees sont plus faciles a suivre pour les non-developpeurs.
• Diffs de controle de version : le SQL formate produit des diffs plus propres lorsque vous changez une clause sans reformater toute la requete.

Comment formater le SQL

1. Collez votre SQL : entrez une requete minifiee ou desordonnee dans le formateur. Il gere SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, et les requetes complexes avec des sous-requetes et des jointures.
2. Configurez les options : choisissez la taille d'indentation et si vous voulez les mots-cles en majuscules. Ces parametres correspondent au guide de style de votre projet.
3. Copiez le resultat : le SQL formate est pret a etre colle de retour dans votre editeur, client de base de donnees ou documentation.

A quoi ressemble un bon formatage

Une requete comme select u.name, o.total from users u join orders o on u.id = o.user_id where o.total > 100 and u.active = 1 order by o.total desc devient :

SELECT
  u.name,
  o.total
FROM users u
JOIN orders o
  ON u.id = o.user_id
WHERE o.total > 100
  AND u.active = 1
ORDER BY o.total DESC

Chaque clause commence sur sa propre ligne. Les conditions sont indentees sous leur clause parente. Les jointures et leurs conditions ON sont clairement appariees.

Une breve histoire des conventions de formatage SQL

SQL a ete cree par les chercheurs IBM Donald Chamberlin et Raymond Boyce en 1974, initialement appele SEQUEL (Structured English Query Language). Le «QL» dans le nom original refletait l'intention que le langage se lise comme l'anglais. Des le debut, cette conception lisible par l'humain impliquait une convention : indentez vos clauses pour qu'elles se lisent de haut en bas comme des phrases.

Pendant la plus grande partie des annees 1980 et 1990, le SQL etait ecrit a la main dans des editeurs de texte et le formatage etait personnel. Certains ateliers ont adopte le «style fleuve» (ou chaque mot-cle s'aligne verticalement a droite d'une colonne virtuelle), d'autres ont utilise le «style egyptien» (equivalent accolade-sur-la-meme-ligne), et la plupart utilisaient simplement ce que l'auteur preferait.

Le premier formateur SQL largement utilise etait Apex SQL Formatter (2000), suivi de SQL Complete de Devart (2002) et SQL Prompt de Red Gate (2003). Ces outils ont apporte le formatage de niveau IDE aux developpeurs SQL Server et Oracle. D'ici 2010, chaque IDE majeur (SSMS, DataGrip, DBeaver) avait un formatage SQL integre, et les formateurs en ligne sont devenus standard pour le nettoyage ad hoc.

En 2017, l'ecosysteme des formateurs a change avec sql-formatter (npm), une bibliotheque JavaScript open-source qui alimente la plupart des formateurs SQL bases sur navigateur aujourd'hui, y compris celui-ci. Les formateurs modernes gerent les differences de dialectes (backticks MySQL, fonctions de fenetre PostgreSQL, crochets carres SQL Server) et produisent une sortie coherente et configurable.

Guides de style SQL utilises par les grandes entreprises

La plupart des bases de code professionnelles suivent l'un des plusieurs guides de style SQL publies :

Si vous demarrez un nouveau projet, choisissez l'un des guides etablis. Si vous rejoignez une base de code existante, suivez ce qui est deja la. La coherence au sein d'un projet importe plus que tout style specifique.

Choix de formatage courants

• Casse des mots-cles : MAJUSCULES (le plus courant, rend les mots-cles visuellement distincts), minuscules (style moderne dbt/Snowflake), ou casse originale (certains IDE preservent ce que vous avez tape).
• Casse des identifiants : snake_case est la valeur par defaut dans PostgreSQL et la plupart des bases de donnees compatibles Unix ; PascalCase ou camelCase dans les traditions Oracle/SQL Server.
• Indentation : 2 espaces (compact, tient dans un terminal de 80 caracteres), 4 espaces (correspond a la plupart des guides de style de code), ou tabulations (rare en SQL).
• Placement des virgules : virgules en fin (apres chaque colonne sur une ligne separee) ou virgules en tete (virgule au debut de la ligne suivante, plus facile a ajouter/supprimer des colonnes).
• Longueur de ligne : 80 caracteres (compatible terminal), 120 caracteres (defaut moderne d'IDE), ou illimitee (moins courant en production).
• Style JOIN : mot-cle ANSI JOIN (prefere) vs ancien style FROM separe par virgules avec conditions de jointure WHERE (deprecie).
• Formatage des sous-requetes : indenter les sous-requetes entre parentheses, utiliser des expressions de table communes (CTE) pour la clarte, ou imbriquer avec des alias explicites.

Differences de dialectes

Les formateurs SQL doivent gerer la syntaxe specifique aux dialectes :

Un bon formateur detecte ou accepte un indice de dialecte, puis gere la syntaxe que d'autres dialectes rejetteraient.

Pieges courants

• Reformatage dans les scripts de production : changer les espaces dans un script de migration qui a deja ete partiellement applique peut causer des problemes si votre outil de migration prend l'empreinte par hash. Formatez avant la premiere execution.
• Litteraux de chaine reformates : une chaine multi-ligne dans une requete ne devrait pas etre reformatee par le formateur SQL ; certains formateurs naifs brisent les chaines inline.
• Commentaires perdus ou mal places : les commentaires SQL (tirets sur une ligne et slash-etoile multi-lignes) doivent survivre au formatage. Certains formateurs les abandonnent ou les deplacent de facon confuse.
• Citation d'identifiant changee : les identifiants entre guillemets doubles en PostgreSQL ou entre backticks en MySQL ont des significations specifiques. Un formateur qui «normalise» en enlevant les guillemets peut changer le comportement de la requete si l'identifiant en avait besoin (mot reserve, casse mixte en PostgreSQL).
• Fonctions de fenetre mal formatees : OVER (PARTITION BY x ORDER BY y) doit rester lisible. Le retour a la ligne agressif a l'interieur des parentheses de fonction de fenetre produit une sortie desordonnee.
• Chaines CTE sur-indentees : WITH cte1 AS (...), cte2 AS (...) peut etre imbrique trop profondement par certains formateurs. La plupart des formateurs modernes gardent les CTE au niveau superieur.
• Chaines entre dollars (fonctions PostgreSQL) : les corps de fonction enveloppes dans $$ ne devraient pas avoir leur contenu reformate. Certains formateurs les massacrent.
• Mots-cles specifiques au fournisseur mal classes : un formateur qui ne connait pas QUALIFY (Snowflake) ou LATERAL (PostgreSQL) peut ne pas les capitaliser ou les aligner correctement.
• Procedures stockees avec flux de controle : les blocs BEGIN/END, IF/THEN/ELSE en T-SQL ou PL/SQL ont besoin de regles d'indentation differentes des requetes pures.

Conseils

• Formatez avant de commiter : passez votre SQL par un formateur avant de l'ajouter au controle de version. Cela garde les diffs propres et les revues concentrees sur la logique, pas le style.
• Utilisez une casse de mots-cles coherente : choisissez des mots-cles en majuscules ou minuscules et restez avec dans tout votre projet. Melanger les styles rend les requetes plus difficiles a lire.
• Decomposez les requetes complexes : si une requete est encore difficile a lire apres le formatage, envisagez de la decomposer en CTE (Common Table Expressions) ou vues. Le formatage ne peut pas corriger une logique fondamentalement complexe.
• Verifiez la coloration syntaxique : un bon formateur fournit une coloration codee qui rend les mots-cles, chaines et nombres visuellement distincts, ce qui aide a attraper les fautes de frappe.
• Formatez seulement ce que vous changez : dans une grande base de code existante, reformater tout d'un coup produit un enorme diff qui obscurcit les vrais changements. Formatez incrementalement au fur et a mesure que vous touchez aux requetes.
• Configurez votre editeur : VS Code (SQLTools, vscode-sql-formatter), DataGrip, DBeaver et pgAdmin ont tous des formateurs integres ou basees sur extensions. Configurez une fois et oubliez.
• Attention aux bases de donnees sensibles a la casse : PostgreSQL est sensible a la casse pour les identifiants entre guillemets. Un formateur qui change la casse des identifiants entre guillemets cassera les requetes.
• Testez la requete formatee : apres le reformatage, executez la requete pour verifier que la sortie est inchangee. La plupart des formateurs sont fiables, mais un bogue dans le formateur peut corrompre une requete.
• Utilisez les CTE plutot que les sous-requetes imbriquees : une chaine CTE est presque toujours plus facile a lire et deboguer que la sous-requete imbriquee equivalente, meme apres formatage.

Confidentialite et requetes sensibles

Le formateur SQL s'execute entierement dans votre navigateur. Les requetes que vous collez, le traitement intermediaire et la sortie formatee restent tous sur votre appareil. Rien n'est televerse sur un serveur, enregistre ou partage avec qui que ce soit.

Cela importe car les requetes SQL contiennent souvent des informations extremement sensibles : noms de tables qui revelent l'architecture du produit, noms de colonnes qui exposent la logique metier et les metriques, vrais ID clients dans les clauses WHERE, points de terminaison d'API internes dans les procedures stockees, SSN et numeros de cartes de credit dans les donnees de test, remuneration des employes dans les requetes RH, chiffres financiers dans les requetes d'analyse, adresses e-mail des clients dans les requetes marketing. Les formateurs SQL en nuage enregistrent chaque requete dans leurs journaux de requetes, les conservent parfois pour «amelioration du service», et ont ete impliques dans de vraies breches ou des requetes de production collees ont fui des schemas et donnees sensibles. Un formateur base sur navigateur a une exposition nulle : la requete ne quitte jamais votre machine.

Le formatage base sur navigateur fonctionne aussi hors ligne une fois la page chargee, utile pour formater des requetes dans les avions, dans des environnements securises sans acces internet, ou partout ou vous ne pouvez pas ou ne devriez pas coller une requete de base de donnees dans un service tiers.