Formateur SQL gratuit

SQL, brève histoire du langage qu'on formate

SQL (Structured Query Language) a été développé chez IBM par Donald D. Chamberlin et Raymond F. Boyce au début des années 1970, à l'origine sous le nom SEQUEL (« Structured English Query Language »), renommé en SQL après un conflit de marque. Le langage a été commercialisé pour la première fois par le prédécesseur d'Oracle (Relational Software, Inc.) en 1979, Oracle V2 fut la première base de données SQL commerciale, devançant le DB2 d'IBM lui-même sur le marché. Le premier standard ANSI, ANSI SQL-86, a été publié en 1986 ; la révision bien plus substantielle SQL-92 (le « grand » standard SQL, ISO/IEC 9075:1992) a défini la majeure partie de la syntaxe que les utilisateurs modernes reconnaissent, syntaxe JOIN, opérations ensemblistes, sous-requêtes, transactions. Les révisions suivantes ont ajouté des fonctionnalités objet-relationnelles (SQL:1999), le support XML (SQL:2003), les fonctions fenêtre et les CTE (SQL:2003 et 2008), les requêtes temporelles (SQL:2011), le support JSON (SQL:2016, étendu en SQL:2023). Chaque grand fournisseur de bases de données implémente son propre dialecte, MySQL, PostgreSQL, SQLite, Microsoft SQL Server (T-SQL), Oracle (PL/SQL), DuckDB (SQL analytique compatible PostgreSQL), BigQuery, Snowflake, Redshift, ClickHouse, Databricks SQL: tous partageant le cœur SQL-92 mais divergeant sur les fonctions, les extensions de syntaxe et les listes de mots réservés. Un bon formateur respecte le dialecte qu'il formate parce que le même identifiant pourrait être un mot-clé dans un dialecte et un nom de colonne légal dans un autre.

Les conventions qui rendent le SQL lisible

Plusieurs conventions sont devenues standard dans les guides de style SQL, celui de Mozilla, le très cité SQL Style Guide de Simon Holywell, les conventions de l'équipe data de GitLab, le style recommandé par dbt. Mots-clés en MAJUSCULES (SELECT, FROM, WHERE, JOIN) versus identifiants (noms de tables et colonnes) en minuscules ou snake_case est la convention dominante. Certains guides de style prônent l'inverse (les mots-clés en minuscules sont plus faciles à taper et à lire), et la documentation officielle de PostgreSQL utilise les mots-clés en minuscules tout du long, mais les MAJUSCULES l'emportent dans la plupart des bases de code professionnelles parce qu'elles rendent la structure du langage visible au premier coup d'œil. Chaque clause majeure sur sa propre ligne : SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, chacune commence une nouvelle ligne au même niveau d'indentation. Les conditions de JOIN indentées sous ON : le mot-clé JOIN sur sa propre ligne, le mot-clé ON sur la ligne suivante indenté d'un niveau. Virgule en début ou en fin dans les listes de colonnes est un débat stylistique de longue date ; virgule en début (chaque ligne de colonne commence par la virgule) produit des diffs plus propres lors d'ajouts/suppressions de colonnes et protège contre l'erreur de syntaxe de virgule traînante, mais paraît visuellement inhabituelle à beaucoup. Virgule en fin est plus courante en code de production. Indentation des sous-requêtes : requêtes imbriquées indentées d'un niveau de plus que leur parent. Clauses CTE (WITH) : chaque CTE nommée sur sa propre ligne, le corps indenté sous le AS, la requête principale en bas alignée à gauche.

Quand vous prendrez un formateur SQL

• Lire les requêtes loguées par un ORM. Hibernate, Sequelize, ActiveRecord, Prisma, SQLAlchemy, Django ORM, tous génèrent du SQL programmatiquement et l'émettent en une seule ligne dense dans vos logs applicatifs. Pour déboguer « pourquoi cette requête est lente », collez le SQL logué dans le formateur et lisez ce que l'ORM a réellement produit. Le résultat est souvent éclairant (« ah, c'est un CROSS JOIN là où je m'attendais à un INNER »).
• Revue de code sur des PR de base de données. Une migration SQL ou un changement de procédure stockée est bien plus facile à relire quand il est formaté de manière cohérente. Passez le fichier dans le formateur avant de commiter pour que le diff soit structurel, pas du bruit d'espacement.
• Lire les plans EXPLAIN à côté de la requête. Lors du tuning d'une requête lente, vous lisez la sortie EXPLAIN, puis vous relisez la requête pour trouver la référence de table en haut du plan. Une requête formatée rend le rapprochement instantané.
• Coller du SQL dans des tickets, des docs, Slack. Une requête formatée se lit clairement ; une requête minifiée sur une seule ligne est illisible dans tout contexte étroit. Formatez avant de partager.
• Reformater des requêtes legacy avec des mots-clés en casse mixte. Une base de code de 15 ans où SELECT était parfois écrit Select, parfois select, parfois SELECT se lit mieux après que le formateur ait tout normalisé en une seule convention.
• Nettoyer des requêtes exportées depuis des outils BI. Looker, Mode, Metabase, Tableau et outils similaires vous laissent copier le SQL sous-jacent mais l'émettent dans le format ad hoc qu'ils génèrent. Formatez avant de lire.

L'écosystème des formateurs SQL

Pour les workflows en ligne de commande et intégrés à l'éditeur, plusieurs options matures existent. sql-formatter (paquet npm, à l'origine d'Andriy Isayev, désormais maintenu par une équipe communautaire) est le formateur SQL dominant de l'écosystème JavaScript, il prend en charge MySQL, PostgreSQL, SQLite, Standard SQL, BigQuery, Redshift, Snowflake, Spark, TiDB, MariaDB et plusieurs autres dialectes. pg_format (Gilles Darold) est le formateur canonique spécifique à PostgreSQL, écrit en Perl et fourni avec le service web populaire pgFormatter. Poor Man's T-SQL Formatter (Tao Klerks, 2011) cible spécifiquement le dialecte T-SQL de Microsoft SQL Server. sqlparse (Andi Albrecht) est la bibliothèque Python standard, utilisée par Django pour l'analyse de requêtes et par d'innombrables scripts d'ingénierie de données. SQLFluff est le linter-et-formateur moderne qui s'intègre aux projets dbt et aux workflows analytiques. DataGrip de JetBrains et le plugin SQL pour IntelliJ IDEA incluent un formateur sophistiqué, conscient du dialecte ; SQLTools de VS Code et plusieurs autres extensions enveloppent la bibliothèque npm sql-formatter. Pour les projets avec un pipeline de build, le motif moderne est « formatage à l'enregistrement dans l'éditeur + un check CI qui fait échouer le build si les fichiers SQL sont mal formatés », même modèle que Prettier pour JavaScript ou Black pour Python.

Différences de dialecte qui comptent pour le formatage

La plupart des formateurs SQL fonctionnent à travers les dialectes avec des ajustements mineurs, mais une poignée de différences exigent que le formateur sache quel dialecte il lit. Identifiants entre guillemets : SQL standard utilise les guillemets doubles ("order") ; MySQL utilise par défaut les backticks (`order`) et ne respecte les guillemets doubles qu'en mode ANSI ; SQL Server utilise les crochets ([order]). Concaténation de chaînes : SQL standard utilise || ; MySQL utilise CONCAT() ou le rare || en mode ANSI ; SQL Server utilise +. Pagination : MySQL/PostgreSQL/SQLite utilisent LIMIT/OFFSET ; SQL Server utilise TOP ou OFFSET FETCH ; Oracle utilise FETCH ou ROWNUM. Auto-incrément : AUTO_INCREMENT en MySQL, SERIAL ou IDENTITY en PostgreSQL, IDENTITY en SQL Server, AUTOINCREMENT en SQLite. Les listes de mots réservés divergent, une colonne nommée rank a besoin d'être entre guillemets en PostgreSQL (où RANK est un mot-clé de fonction fenêtre) mais passe comme identifiant en MySQL. Un formateur qui ne connaît pas le dialecte peut casser des requêtes valides en ajoutant des guillemets inappropriés. La sortie « Format SQL » d'un formateur générique est généralement correcte pour la forme standard SELECT/INSERT/UPDATE/DELETE ; pour la syntaxe propre au fournisseur (fonctions fenêtre, hints, fonctions système), vérifiez la sortie par rapport à la documentation de votre dialecte.

Confidentialité : pourquoi le tout-navigateur compte particulièrement pour le SQL

Les requêtes SQL font partie des textes les plus sensibles dans n'importe quelle organisation : elles exposent des noms de tables internes (qui révèlent la taxonomie produit), des noms de colonnes (qui révèlent le modèle de données), des valeurs de filtre (qui peuvent inclure de vrais identifiants utilisateur, des adresses e-mail, des identifiants métier), des credentials littéraux embarqués dans des patterns plus anciens, et la structure d'analyses que l'entreprise peut considérer comme propriétaires. Les formateurs SQL côté serveur prennent une copie de chaque requête dans leurs logs. Ce formateur tourne entièrement dans votre navigateur via JavaScript, vérifiez dans l'onglet Réseau des DevTools en cliquant sur Format (aucune requête ne part), ou mettez la page hors ligne (mode avion) après son chargement et le formateur fonctionne toujours. Sûr pour les requêtes de production contenant de vrais noms de tables et des valeurs de filtre PII, du SQL analytique interne, des pipelines ETL, ou toute requête que vous ne voudriez pas voir copiée sur le disque dur d'un inconnu.

Questions fréquentes

Le formateur peut-il mettre automatiquement les mots-clés SQL en majuscules ?

Oui, le bouton Mots-clés contrôle la casse. MAJUSCULES est la convention professionnelle dominante parce qu'elle rend la structure du langage visible au premier coup d'œil (SELECT, FROM, WHERE ressortent des identifiants) ; minuscules est préférée par certains guides de style (la documentation officielle de PostgreSQL utilise les minuscules tout du long) au motif que c'est plus facile à lire et plus rapide à taper. Les deux fonctionnent tant que votre équipe en choisit une et l'utilise de manière cohérente. La capitalisation n'a aucun effet sur le comportement de la requête, les mots-clés SQL sont insensibles à la casse au moment du parsing.

Comment personnaliser l'indentation ?

Le menu Indentation prend en charge 2 espaces (la convention web moderne dominante), 4 espaces (encore courants dans les anciens shops Java et .NET), ou les caractères de tabulation. 2 espaces tend à l'emporter dans les bases de code récentes et pour SQL en particulier parce que l'imbrication profonde de sous-requêtes tient plus confortablement dans une limite de ligne de 100 caractères. Adaptez à la convention que votre équipe utilise déjà ; la cohérence compte plus que le choix précis.

Cela fonctionne-t-il avec de grandes requêtes ?

Oui, comme le formatage tourne dans votre navigateur, le plafond pratique est la mémoire disponible de votre appareil. Des centaines de lignes de SQL se formatent en bien moins d'une seconde ; les requêtes de plusieurs milliers de lignes (typiques en ETL d'entrepôt de données) fonctionnent mais peuvent figer brièvement l'onglet pendant que le parser parcourt la structure. Pour le reformatage en lot d'un dépôt SQL entier, les outils en ligne de commande (sql-formatter via npm, pg_format pour PostgreSQL, SQLFluff pour les projets dbt) sont plus appropriés.

Le formateur reconnaîtra-t-il mon dialecte SQL spécifique ?

Il gère correctement les formes courantes SELECT/INSERT/UPDATE/DELETE/JOIN/CTE/sous-requête à travers MySQL, PostgreSQL, SQLite, T-SQL et SQL ANSI standard. La syntaxe propre au fournisseur, clauses de fonctions fenêtre, instructions MERGE, hints spécifiques au dialecte, fonctions système, opérateurs de tableau de style PostgreSQL, méthodes XML T-SQL, peut se formater imparfaitement. Vérifiez la sortie ponctuellement et exécutez la requête formatée dans votre base de données pour confirmer qu'elle parse correctement avant de commiter.

Mon SQL est-il téléversé ?

Non. Le formatage tourne entièrement dans votre navigateur, les requêtes collées ne quittent jamais votre appareil. Vérifiez dans l'onglet Réseau des DevTools en cliquant sur Format (aucune requête ne part), ou mettez la page hors ligne (mode avion) après son chargement. Sûr pour les requêtes de production contenant des noms de tables sensibles, des valeurs de filtre PII, ou tout SQL couvert par un NDA ou une réglementation de conformité.

Outils associés