Formateur SQL
Formatez et embellissez les requetes SQL. Collez du SQL desordonne et obtenez une sortie propre et indentee avec coloration syntaxique.
Fonctionnalites principales
- Mise en majuscules automatique des mots-clés
- Indentation configurable
- Coloration syntaxique
- Prise en charge des dialectes SQL courants
Guide
Le formatage SQL transforme des requêtes denses et illisibles en code structuré, constamment indenté, facile à lire, réviser, déboguer et maintenir. Une requête qui fonctionne parfaitement écrite sur une seule ligne devient un fardeau de maintenance lorsque quelqu'un d'autre (ou vous, trois mois plus tard) a besoin de comprendre ce qu'elle fait. Un formatage SQL cohérent n'est pas cosmétique. Il réduit les bugs, accélère la revue de code et rend les requêtes complexes traitables. Ce guide couvre les conventions de formatage, la structure des clauses, les motifs courants pour différents types de requêtes, et la façon dont le formatage interagit avec l'optimisation des requêtes. La règle fondamentale du formatage SQL est une clause par ligne. SELECT, FROM, WHERE, JOIN, ON, GROUP BY, HAVING, ORDER BY, LIMIT, INSERT INTO, VALUES, UPDATE, SET et DELETE FROM commencent chacun sur leur propre ligne au niveau d'indentation de base. Cette structure rend la requête balayable. Vous pouvez voir d'un coup d'œil quelles colonnes sont sélectionnées, quelles tables sont impliquées, quelles conditions filtrent les données et comment les résultats sont triés. Une requête formatée de cette façon se lit comme un document structuré plutôt que comme une phrase interminable. Le formatage de la clause SELECT liste chaque colonne sur sa propre ligne, indentée d'un niveau par rapport au mot-clé SELECT. Les virgules en début de ligne (virgules au début de chaque ligne plutôt qu'à la fin) sont une convention populaire parce qu'elles facilitent la mise en commentaire de colonnes individuelles et produisent des diffs plus propres dans le contrôle de version. Les virgules en fin et en début sont toutes deux acceptables tant que le choix est cohérent à travers le codebase. Les alias de colonne devraient utiliser explicitement le mot-clé AS (column_name AS alias) plutôt que le raccourci (column_name alias) par clarté. Quand une expression de colonne est longue (une instruction CASE ou un appel de fonction avec plusieurs arguments), placez-la sur sa propre ligne et indentez la continuation. Les clauses FROM et JOIN bénéficient d'un alignement cohérent. Chaque JOIN a sa propre ligne à la même indentation que FROM. La condition ON est indentée sous son JOIN. Pour les requêtes avec de nombreuses jointures, cette structure visuelle rend les relations de table claires : FROM orders o JOIN customers c ON c.customer_id = o.customer_id JOIN products p ON p.product_id = o.product_id LEFT JOIN shipping s ON s.order_id = o.order_id Le type de jointure (INNER JOIN, LEFT JOIN, RIGHT JOIN, CROSS JOIN, FULL OUTER JOIN) porte du sens. Un formatage qui sépare visuellement chaque jointure aide les relecteurs à vérifier que le bon type de jointure est utilisé pour chaque relation. Un LEFT JOIN qui devrait être un INNER JOIN (ou inversement) est un bug courant que le code formaté rend plus facile à repérer. Le formatage de la clause WHERE place chaque condition sur sa propre ligne avec AND ou OR au début de la ligne. Indenter les conditions sous WHERE rend la logique de filtre visible : WHERE o.order_date >= '2026-01-01' AND o.status = 'completed' AND c.country = 'US' AND (p.category = 'electronics' OR p.category = 'appliances') La logique booléenne complexe avec des opérateurs AND et OR mélangés est une source courante de bugs. Un formatage avec des parenthèses explicites et une indentation claire montre le regroupement logique. Sans formatage, WHERE a = 1 AND b = 2 OR c = 3 est ambigu pour les lecteurs humains (bien que SQL évalue AND avant OR, donc cela signifie (a = 1 AND b = 2) OR c = 3). Formaté avec des parenthèses, l'intention devient claire. Utilisez toujours des parenthèses avec des AND/OR mélangés pour rendre la précédence explicite. Les sous-requêtes devraient être indentées d'un niveau à l'intérieur de leurs parenthèses. Chaque sous-requête est formatée en utilisant les mêmes règles qu'une requête de niveau supérieur. Les sous-requêtes corrélées (celles référençant des colonnes de la requête externe) sont particulièrement importantes à formater clairement parce que leur relation avec la requête externe détermine leur comportement : SELECT customer_name , total_spent FROM customers c WHERE total_spent > ( SELECT AVG(total_spent) FROM customers WHERE country = c.country ) L'indentation montre que la sous-requête est imbriquée à l'intérieur de la clause WHERE et référence c.country de la requête externe. Pour les sous-requêtes profondément imbriquées (trois niveaux ou plus), envisagez de refactoriser en CTE à la place, car l'imbrication profonde devient difficile à suivre quel que soit le formatage. Les expressions de table communes (CTE) utilisant les clauses WITH devraient être formatées avec chaque CTE comme un bloc nommé séparé : WITH monthly_sales AS ( SELECT DATE_TRUNC('month', order_date) AS month , SUM(amount) AS total FROM orders GROUP BY DATE_TRUNC('month', order_date) ), monthly_avg AS ( SELECT AVG(total) AS avg_total FROM monthly_sales ) SELECT m.month , m.total , a.avg_total FROM monthly_sales m CROSS JOIN monthly_avg a WHERE m.total > a.avg_total Les CTE sont l'une des fonctionnalités SQL les plus puissantes pour découper des requêtes complexes en composants lisibles et testables. Chaque CTE peut être testée indépendamment en exécutant seulement son instruction SELECT. Un formatage approprié rend le but de chaque CTE visible et le flux de données entre CTE traçable. Nommez vos CTE de façon descriptive : monthly_sales est meilleur que cte1. Les clauses GROUP BY et ORDER BY suivent le même motif multi-lignes que SELECT lorsqu'elles référencent plusieurs colonnes. Listez chaque colonne sur sa propre ligne indentée. Pour GROUP BY, cela facilite la vérification que toutes les colonnes SELECT non agrégées sont incluses (une exigence en SQL standard et appliquée par PostgreSQL, bien que MySQL soit permissif par défaut). Pour ORDER BY, lister chaque colonne de tri avec sa direction (ASC ou DESC) sur une ligne séparée clarifie la priorité de tri. Énoncer explicitement ASC (même si c'est le défaut) améliore la lisibilité. Le formatage de la clause HAVING suit les mêmes règles que WHERE. HAVING filtre les groupes après agrégation, et ses conditions devraient être formatées avec une condition par ligne. Une erreur de formatage courante est de placer les conditions HAVING dans la clause WHERE ou inversement. WHERE filtre les lignes avant le regroupement. HAVING filtre les groupes après agrégation. Le placement correct est essentiel à la fois pour l'exactitude et la performance, et un formatage clair rend la vérification facile. Les expressions CASE sont des constructions multi-lignes qui devraient être formatées pour montrer chaque paire WHEN/THEN : SELECT order_id , CASE WHEN status = 'shipped' THEN 'In Transit' WHEN status = 'delivered' THEN 'Complete' WHEN status = 'returned' THEN 'Returned' ELSE 'Processing' END AS status_label FROM orders Les expressions CASE imbriquées (CASE à l'intérieur de CASE) devraient être évitées quand possible parce qu'elles deviennent illisibles quel que soit le formatage. Refactorisez en CTE, colonnes calculées ou une table de référence jointe à la requête à la place. Les instructions INSERT ont deux formats courants. Pour les insertions à une seule ligne avec des colonnes nommées, listez chaque paire colonne-valeur de façon lisible : INSERT INTO customers ( customer_name , email , country , created_at ) VALUES ( 'John Doe' , 'john@example.com' , 'US' , CURRENT_TIMESTAMP ) Aligner les entrées VALUES avec leurs noms de colonne correspondants facilite la vérification que chaque valeur correspond à la bonne colonne. Pour les instructions INSERT...SELECT, formatez la partie SELECT en utilisant les règles standards de formatage SELECT. Les instructions UPDATE bénéficient du formatage de chaque assignation SET sur sa propre ligne : UPDATE customers SET email = 'newemail@example.com' , updated_at = CURRENT_TIMESTAMP , status = 'verified' WHERE customer_id = 12345 Cette structure rend clair quelles colonnes sont modifiées et empêche l'omission accidentelle de la clause WHERE, qui mettrait à jour chaque ligne de la table. La clause WHERE dans les instructions UPDATE et DELETE est la clause la plus critique à obtenir correctement. Un formatage qui place le WHERE sur sa propre ligne au même niveau que UPDATE ou DELETE rend sa présence (ou absence) évidente. Les instructions DELETE devraient toujours avoir leur clause WHERE clairement visible : DELETE FROM order_items WHERE order_id = 12345 AND item_status = 'cancelled' Un DELETE sans WHERE supprime toutes les lignes de la table. Le code formaté rend la présence ou l'absence de WHERE immédiatement visible. Certaines équipes adoptent une convention consistant à toujours écrire les requêtes DELETE d'abord comme des requêtes SELECT (en remplaçant DELETE FROM par SELECT * FROM) pour vérifier quelles lignes seront affectées, puis à reconvertir en DELETE. Les fonctions window font partie des constructions SQL les plus complexes à formater. La clause OVER avec PARTITION BY et ORDER BY devrait être sur ses propres lignes indentées lorsqu'elles sont longues : SELECT customer_id , order_date , amount , SUM(amount) OVER ( PARTITION BY customer_id ORDER BY order_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS running_total FROM orders Pour les spécifications window courtes, les garder sur une ligne est acceptable : ROW_NUMBER() OVER (ORDER BY id) AS row_num. L'objectif est la lisibilité à la longueur et complexité de l'expression réelle. Les définitions window nommées (WINDOW w AS (PARTITION BY customer_id ORDER BY order_date)) suivies de OVER w réduisent la répétition lorsque plusieurs colonnes utilisent la même spécification window. La capitalisation des mots-clés est un choix de style avec des opinions tranchées des deux côtés. Les mots-clés en MAJUSCULES (SELECT, FROM, WHERE) distinguent visuellement la syntaxe SQL des noms de table et de colonne. Les mots-clés en minuscules se fondent mais sont plus faciles à taper. Le plus important est la cohérence. Choisissez une convention et appliquez-la à travers l'équipe. Beaucoup d'organisations utilisent les majuscules pour les mots-clés et les minuscules pour les identifiants. Certains guides de style modernes préfèrent tout en minuscules, arguant que la coloration syntaxique dans les éditeurs distingue déjà les mots-clés des identifiants. Une troisième approche met en majuscules seulement les mots-clés de clause majeurs (SELECT, FROM, WHERE) et laisse les noms de fonction et les mots-clés mineurs en minuscules. Les alias de table devraient être significatifs. Utiliser des alias à une lettre (a, b, c) économise de la frappe mais rend les requêtes plus difficiles à lire, en particulier avec de nombreuses jointures. Les abréviations courtes dérivées du nom de table sont meilleures : customers AS c, orders AS o, order_items AS oi. Dans les requêtes complexes avec de nombreuses tables, des alias plus longs améliorent la clarté : customers AS cust, order_items AS items. Utilisez toujours le mot-clé AS pour les alias pour les distinguer des fautes de frappe ou des virgules oubliées. N'utilisez jamais des mots réservés comme alias. La largeur d'indentation devrait être cohérente. Deux espaces et quatre espaces sont tous deux des choix courants. Tabulations contre espaces est une préférence, mais les espaces produisent un alignement plus cohérent à travers les éditeurs et les outils. L'outil de formatage SQL vous permet de configurer la largeur d'indentation pour correspondre au standard de votre équipe. Quelle que soit la largeur que vous choisissez, utilisez-la uniformément pour tous les niveaux d'indentation : corps de clause, imbrication de sous-requête, corps d'expression CASE et définitions CTE. Le formatage des commentaires en SQL utilise -- pour les commentaires d'une ligne et /* */ pour les commentaires multi-lignes. Placez les commentaires au-dessus de la clause ou expression qu'ils décrivent, pas en ligne à la fin d'une longue ligne où ils pourraient être manqués. Pour la logique métier complexe dans les clauses WHERE, un commentaire expliquant pourquoi une condition existe est précieux : -- Exclure les comptes de test créés par l'équipe QA avant la condition de filtre. Les commentaires qui répètent le SQL (-- Joindre la table customers) ajoutent du bruit sans valeur. Les bons commentaires expliquent l'intention, pas la mécanique. Le formatage et la performance des requêtes ne sont pas directement liés. Le moteur de base de données analyse et optimise la requête indépendamment des espaces et des sauts de ligne. Cependant, les requêtes bien formatées sont plus faciles à optimiser parce que vous pouvez voir la structure clairement. Une requête mal formatée avec un problème de performance cache le problème dans un mur de texte. La même requête, correctement formatée, révèle la sous-requête problématique, la condition de jointure manquante, le DISTINCT inutile ou la clause WHERE non sargable d'un coup d'œil. Le formatage est un outil de débogage et d'optimisation. Le contrôle de version et le formatage SQL interagissent de façons importantes. Reformater une requête entière dans un seul commit produit un diff qui touche chaque ligne, rendant impossible de voir ce qui a réellement changé. Lors de l'adoption d'un formateur pour un codebase existant, faites le formatage dans un commit dédié avec un message clair comme « Appliquer le standard de formatage SQL ». Les changements suivants produisent ensuite des diffs propres et significatifs. Les virgules en début de ligne sont populaires en partie parce qu'ajouter une nouvelle colonne à un SELECT produit un diff d'une ligne (la nouvelle ligne), tandis que les virgules en fin exigent de modifier la ligne précédente pour ajouter une virgule, créant un diff de deux lignes. Les différences de dialecte affectent les choix de formatage. PostgreSQL, MySQL, SQL Server, Oracle, SQLite et BigQuery ont chacun des variations de syntaxe. PostgreSQL utilise le castage par double-deux-points (value::type) et les chaînes délimitées par dollar. MySQL utilise le quoting par accents graves pour les identifiants et LIMIT avec OFFSET. SQL Server utilise le quoting par crochets, TOP au lieu de LIMIT, et CROSS APPLY au lieu de LATERAL JOIN. Oracle utilise ROWNUM, CONNECT BY pour les requêtes hiérarchiques, et différentes fonctions de date. BigQuery utilise le quoting par accents graves pour les noms de table qualifiés par projet. Un formateur devrait gérer le dialecte que votre équipe utilise. L'outil de formatage SQL prend en charge la syntaxe SQL standard qui est compatible avec tous les dialectes majeurs. L'adoption par l'équipe de standards de formatage SQL exige une configuration partagée et idéalement une application automatisée. Incluez les règles de formatage SQL dans votre guide de style de code. Utilisez des hooks pre-commit ou des vérifications CI pour vérifier le formatage sur les fichiers SQL. Définissez le standard dans un fichier de configuration d'outil (comme .sql-formatter.json) qui est commité dans le dépôt. Le coût initial de l'accord sur un standard est remboursé à travers chaque revue de code qui n'inclut plus de remarques de formatage et chaque session de débogage qui commence avec du code lisible plutôt qu'un exercice de reformatage. Le SQL dans le code d'application (intégré en Python, JavaScript, Java ou d'autres langages) pose des défis de formatage supplémentaires. Une chaîne SQL brute à l'intérieur d'une fonction Python ou d'un template literal JavaScript est soumise à la fois aux règles de formatage du langage hôte et aux règles de formatage SQL. Les littéraux de chaîne multi-lignes (triples guillemets Python, accents graves JavaScript) vous permettent de maintenir le formatage SQL dans le code d'application. Séparez la chaîne SQL de la logique d'application : assignez la requête à une constante nommée (const FIND_ACTIVE_USERS = ...) et référencez-la où nécessaire. Pour les grandes collections de requêtes, déplacez le SQL dans des fichiers .sql séparés et chargez-les à l'exécution. Le SQL généré par ORM a souvent besoin de formatage pour le débogage. Quand votre requête Django, SQLAlchemy, ActiveRecord ou Prisma produit des résultats inattendus, visualiser le SQL généré aide à diagnostiquer le problème. La plupart des ORM fournissent un moyen de sortir le SQL brut (query.toString() dans Knex, str(query) dans SQLAlchemy, .explain() dans Django). Collez le SQL généré dans un formateur pour comprendre sa structure. Le SQL généré par ORM est typiquement dense et difficile à lire parce qu'il n'a jamais été destiné aux humains. La sortie formatée rend les jointures, conditions et sous-requêtes visibles. Les procédures stockées et les fonctions exigent une discipline de formatage au-delà des requêtes individuelles. Chaque procédure contient plusieurs instructions SQL, des déclarations de variables, un flux de contrôle (IF/ELSE, WHILE, FOR) et une gestion des exceptions (TRY/CATCH, BEGIN/EXCEPTION). Formatez chaque instruction SQL à l'intérieur de la procédure en utilisant les règles standards de formatage de requête. Indentez les corps de flux de contrôle d'un niveau par rapport à leurs mots-clés. Placez BEGIN et END sur leurs propres lignes. Ajoutez des lignes vides entre les sections logiques à l'intérieur de la procédure. Les procédures stockées bien formatées sont dramatiquement plus faciles à déboguer que les procédures denses et non formatées. Les fichiers de migration bénéficient du formatage SQL parce qu'ils sont révisés dans les pull requests et représentent des changements permanents de schéma de base de données. Une instruction CREATE TABLE avec des définitions de colonnes formatées est facile à réviser pour les types de données corrects, les contraintes, la nullabilité et les valeurs par défaut. Un ALTER TABLE avec plusieurs instructions ADD COLUMN devrait lister chaque colonne sur sa propre ligne. Le formatage rend la révision de migration plus rapide et réduit le risque de livrer une migration avec des types de colonnes incorrects ou des contraintes manquantes. Les requêtes d'analyse de performance (EXPLAIN, EXPLAIN ANALYZE) produisent une sortie plus facile à corréler avec la requête lorsque la requête elle-même est formatée. Si vous collez une requête d'une ligne dans EXPLAIN ANALYZE, la sortie référence des opérations sur des composants de requête spécifiques qui sont difficiles à localiser dans la chaîne d'une ligne. La même requête, correctement formatée, vous permet de faire correspondre chaque ligne du plan d'exécution à la clause correspondante dans la requête. Cette corrélation est essentielle pour identifier quelle jointure ou sous-requête cause des problèmes de performance. La génération dynamique de SQL dans le code d'application devrait produire une sortie formatée. Lors de la construction de requêtes par programmation (construction de chaînes SQL basée sur une saisie utilisateur ou une configuration), ajoutez des sauts de ligne et une indentation à la requête générée. Cela ne coûte rien à l'exécution mais rend la journalisation et le débogage dramatiquement plus faciles. Quand une requête générée cause une erreur ou performe mal, vous pouvez lire le SQL formaté dans le journal et comprendre immédiatement la structure. Tout concaténer sur une ligne économise quelques caractères mais crée des maux de tête de débogage. Les listes de vérification de revue de code SQL bénéficient des standards de formatage. Un relecteur vérifiant du SQL formaté peut vérifier systématiquement : des types de jointure corrects pour chaque relation de table, des conditions de clause WHERE qui correspondent à l'exigence métier, un GROUP BY incluant toutes les colonnes non agrégées, un ORDER BY reflétant le tri attendu, une utilisation appropriée de LEFT JOIN contre INNER JOIN (un LEFT JOIN où un INNER suffirait indique soit un bug soit une prudence inutile), et l'absence d'anti-patterns courants comme SELECT * dans le code de production, les jointures croisées implicites, et les sous-requêtes corrélées qui pourraient être réécrites en jointures. Formater de grandes requêtes héritées est l'un des usages les plus précieux d'un formateur SQL. Les bases de données d'entreprise accumulent des requêtes sur des années ou des décennies. Les requêtes écrites par des développeurs qui ont depuis longtemps quitté l'entreprise, modifiées plusieurs fois, et jamais reformattées deviennent des murs de texte que personne n'ose toucher. Passer ces requêtes dans un formateur est la première étape pour les rendre maintenables. Formatez la requête, commit le changement de formatage séparément, puis commencez le travail de modification réel avec un point de départ lisible. L'outil de formatage SQL prend n'importe quelle requête SQL valide, analyse sa structure, et produit du SQL constamment formaté suivant des règles configurables pour l'indentation, la casse des mots-clés et le placement des clauses. Collez votre requête, cliquez sur formater, et copiez le résultat. Utilisez-le pour formater les requêtes avant de commettre, nettoyer le SQL hérité pour la révision, standardiser les requêtes reçues de collègues ou générées par des outils ORM, et préparer le SQL pour la documentation ou les présentations.
Questions frequentes
Quels dialectes SQL sont pris en charge ?
Le formateur prend en charge la syntaxe SQL standard, y compris SELECT, JOIN, WHERE, GROUP BY et autres clauses courantes.
Cela modifie-t-il la logique de ma requête ?
Non, le formateur ne change que les espaces et la casse. La logique de votre requête reste exactement la même.
