Formateur SQL — MySQL, PostgreSQL, BigQuery, Snowflake en ligne

Les équipes data de Decathlon qui migrent leurs modèles analytiques vers Snowflake appliquent le formatage SQL comme critère de validation avant merge. Quand un ingénieur formate à la main un CTE de 200 lignes et qu'un autre le colle en une seule ligne, le diff devient illisible et noie le changement réel. Doctolib a adopté le guide de style SQL de dbt Labs pour uniformiser les modèles PostgreSQL partagés entre les équipes produit et data, et BlaBlaCar utilise les conventions BigQuery par défaut que sql-formatter reproduit fidèlement. Passer les requêtes dans un formateur cohérent avant chaque commit réduit les cycles de relecture et isole le vrai changement — un nouveau champ, une jointure, un prédicat WHERE — sur sa propre ligne.

Comment fonctionne le formatage SQL

Le formatage SQL est une réécriture pilotée par un lexer qui parcourt chaque token de la requête et le réémet avec les espaces blancs appropriés selon les règles du dialecte choisi. La sémantique de la requête ne change jamais, seule la mise en page est modifiée.

Choisir un dialecte. Les accents graves MySQL, les casts :: PostgreSQL, les chemins de table pointés BigQuery et les identifiants entre crochets T-SQL nécessitent chacun un tokeniseur qui les reconnaît. Le sélecteur de dialecte choisit quelle grammaire appliquer.
Tokeniser l'entrée. Le formateur découpe la requête en un flux de tokens : mots-clés (SELECT, JOIN), identifiants, littéraux, opérateurs, parenthèses et commentaires. Les littéraux de chaîne et les identifiants entre guillemets sont transmis sans modification afin que la syntaxe spécifique au dialecte continue de fonctionner.
Appliquer les règles de mise en page. Les clauses de haut niveau (SELECT, FROM, WHERE, GROUP BY, ORDER BY) commencent sur leur propre ligne. Les expressions séparées par des virgules dans la liste de sélection et les listes de colonnes obtiennent chacune une ligne, indentée de l'unité d'indentation choisie.
Appliquer la casse des mots-clés. Le sélecteur de casse réécrit les mots-clés SQL reconnus en majuscules, en minuscules ou conserve la casse d'origine. Les identifiants ne sont jamais touchés — les noms de colonnes et de tables sont toujours transmis tels qu'ils ont été écrits.
Émettre la chaîne formatée. Le flux de tokens est réassemblé en une seule chaîne avec le caractère d'indentation (2 espaces, 4 espaces ou tabulation) et la règle de saut de ligne configurée. Le mode en direct ré-exécute tout le pipeline avec un debounce de 200 ms pendant la saisie.

Pourquoi embellir le SQL

Lisibilité des diffs de pull request. Un CTE de 200 lignes réécrit sur une seule ligne transforme la revue de code en devinette. Un formatage cohérent limite le diff au changement que vous avez réellement effectué — une nouvelle colonne, un JOIN supplémentaire, un prédicat WHERE différent — afin que le relecteur puisse le voir sans démêler les espaces.
Débogage facilité. Quand une requête renvoie un mauvais nombre de lignes, la première chose à faire est de la lire ligne par ligne. Le SQL formaté place chaque JOIN sur sa propre ligne et aligne les prédicats WHERE, de sorte qu'un AND manquant ou un OR parasite apparaît au premier coup d'œil.
Style d'équipe cohérent. La plupart des équipes adoptent un guide de style SQL (dbt Labs, GitLab, Mode Analytics les publient tous) et souhaitent que chaque requête commitée le respecte. Un formateur exécuté avant le commit supprime la discussion de style lors de la relecture et ne laisse que la logique à débattre.
Partager du SQL dans la documentation. Les runbooks, les retros d'incidents et les documents Notion bénéficient d'un SQL qui se lit de haut en bas. Le SQL formaté se colle proprement dans un bloc de code délimité et s'imprime de façon prévisible dans les exports PDF, sans retours à la ligne maladroits en plein milieu d'un mot-clé.

Applications courantes

Le formatage SQL apparaît en ingénierie analytique, en développement backend et en opérations dès qu'une requête doit être lue par quelqu'un qui ne l'a pas écrite.

Ingénierie analytique : hook de pré-commit dans un projet dbt qui reformate chaque fichier de modèle afin que les diffs de PR restent limités aux changements de logique et non aux variations d'espaces.
Administration de bases de données : coller une entrée de slow-query log sur une ligne, la formater et parcourir l'ordre des jointures en rédigeant la retro d'incident.
Documentation : extraire une requête d'un explore Looker ou d'un classeur Tableau, la formater pour un runbook et l'intégrer comme exemple prêt à copier-coller pour l'astreinte.

Un exemple concret

Collez SELECT u.id,u.email,COUNT(o.id) FROM users u LEFT JOIN orders o ON o.user_id=u.id WHERE u.created_at > '2024-01-01' GROUP BY u.id,u.email ORDER BY u.id; dans le panneau d'entrée avec le dialecte défini sur PostgreSQL, une indentation de 2 espaces et la casse MAJUSCULES. La sortie place SELECT, FROM, LEFT JOIN, WHERE, GROUP BY et ORDER BY sur leurs propres lignes ; chaque colonne de la liste de sélection et de la liste GROUP BY obtient sa propre ligne indentée ; et le prédicat ON est indenté d'un niveau de plus que le mot-clé JOIN auquel il appartient.

FAQ

Quels dialectes SQL sont pris en charge ?

Le menu de dialectes couvre SQL standard, MySQL, PostgreSQL, SQLite, MariaDB, Transact-SQL (SQL Server / Azure SQL), BigQuery, Snowflake et Redshift. La bibliothèque sql-formatter sous-jacente reconnaît également DuckDB, Spark SQL, Hive, Trino, Db2, N1QL, PL/SQL, ClickHouse, TiDB et SingleStoreDB — choisir le dialecte le plus proche produit une sortie sensée même quand la cible exacte n'est pas dans la liste. Les identifiants, les littéraux de chaîne et les opérateurs spécifiques au dialecte (PostgreSQL @>, préfixes BigQuery SAFE.) sont préservés tels quels.

Cet outil valide-t-il mon SQL ?

Non. Le formateur est un réécriture lexicale, pas un analyseur syntaxique. Il tokenise l'entrée, applique des règles de mise en page et émet le résultat ; il ne vérifie pas si la requête est sémantiquement valide, si les tables référencées existent ou si la syntaxe est légale dans le dialecte choisi. Exécutez la sortie formatée dans la vraie base de données (ou dans un linter SQL comme SQLFluff) pour un vrai contrôle de validité.

Pourquoi mes mots-clés passent-ils en majuscules ?

Le menu de casse des mots-clés est réglé par défaut sur MAJUSCULES, ce qui correspond à la convention de la plupart des guides de style SQL publiés (dbt Labs, Mode, GitLab). Passez sur minuscules si votre équipe écrit select / from en minuscules, ou sur Conserver si vous souhaitez que la sortie garde la casse que vous avez tapée. Les identifiants ne sont jamais affectés — seul l'ensemble des mots-clés reconnus est réécrit.

Ma requête est-elle envoyée quelque part ?

Non. La bibliothèque sql-formatter embarquée s'exécute dans votre navigateur, le formatage se passe localement sur votre machine et le texte de la requête ne traverse jamais le réseau. Les seules requêtes sortantes que cette page émet sont les mêmes requêtes d'analytics et de publicité que toutes les pages de tools.ultim8soft.com ; le texte SQL lui-même n'en fait pas partie.

Le SQL joliment formaté cesse d'être un sujet de discussion stylistique dès qu'un formateur s'en charge. L'outil tourne entièrement dans votre navigateur, la requête ne quitte jamais la page, et le même tokeniseur conscient du dialecte qui alimente le paquet npm sql-formatter effectue la réécriture.

Formater des requêtes SQL _

// Outils Connexes