Formateur SQL
Formatez et embellissez du SQL pour PostgreSQL, MySQL, SQLite et plus encore.
À propos de cet outil
Collez une requête, même une longue ligne unique issue d’un log, et obtenez-la mise en forme avec une clause par ligne. Choisissez le dialecte SQL, la casse des mots-clés et l’indentation.
Mode d’emploi
- Collez une requête, par exemple une longue ligne unique copiée depuis un log ou la sortie de débogage d’un ORM.
- Choisissez le dialecte de votre base de données pour que ses mots-clés et sa syntaxe soient reconnus.
- Choisissez la casse des mots-clés (MAJUSCULES, minuscules ou telle que saisie) et l’indentation, ou Une ligne pour compacter.
- Copiez la requête formatée.
Questions
- Quelles bases de données sont prises en charge ?
- SQL standard, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, DuckDB, ClickHouse, Spark SQL et Trino/Presto.
- Le formatage change-t-il ce que fait la requête ?
- Non. Seuls les espaces et, si vous le souhaitez, la casse des mots-clés changent. Les identifiants, les chaînes littérales et la logique de la requête restent strictement identiques.
- Puis-je formater plusieurs requêtes à la fois ?
- Oui. Séparez-les par des points-virgules : chaque requête est formatée séparément, avec une ligne vide entre elles.
- Ma requête est-elle envoyée quelque part ?
- Non. Le formatage s’exécute dans votre navigateur : les requêtes contenant des noms de tables ou des données de production ne quittent donc jamais votre machine.
- Le formateur SQL vérifie-t-il les erreurs de ma requête ?
- Non. Il met en page les tokens mais ne valide pas la requête auprès d’une base de données ou d’un schéma : select a, from t est donc formaté sans protester. Les erreurs n’apparaissent que si le texte ne peut pas du tout être lu dans le dialecte choisi. Exécutez la requête, ou passez-la à EXPLAIN, pour trouver les vraies erreurs.
- L’option Une ligne est-elle sûre pour les requêtes avec des commentaires -- ?
- Pas toujours. Un commentaire -- s’étend jusqu’à la fin de la ligne : une fois la requête ramenée sur une seule ligne, tout ce qui suit le commentaire en fait partie. Supprimez les commentaires -- ou réécrivez-les en /* … */ avant d’utiliser Une ligne. Les commentaires de bloc ne posent pas de problème sur une seule ligne.
- Peut-on formater des modèles dbt ou d’autres SQL à base de templates ?
- Pas directement. Les balises de template écrites entre doubles accolades, ainsi que les blocs de contrôle comme if et for, ne sont pas du SQL : le formateur s’arrête donc sur une erreur d’analyse dès la première balise. Compilez d’abord le modèle, par exemple avec dbt compile, puis formatez le SQL généré.
À quoi sert un formateur SQL ?
Un formateur SQL réécrit une requête pour rendre sa structure visible. Chaque clause, comme SELECT, FROM, JOIN, WHERE, GROUP BY et ORDER BY, commence sur sa propre ligne, les colonnes et conditions qui en dépendent sont indentées, et les parenthèses ouvrent un bloc indenté. Une requête sur une ligne comme select id, email from users where active = true and (plan = 3 or trial = true) devient une douzaine de lignes courtes où l’on voit quelles conditions vont ensemble.
La casse des mots-clés est une question de convention. MAJUSCULES est le style traditionnel qui distingue les mots-clés des noms de tables et de colonnes, minuscules est courant dans les guides de style récents et les équipes d’analyse de données, et Tel que saisi laisse les mots-clés intacts quand vous voulez seulement corriger la mise en page. Choisissez 2 ou 4 espaces d’indentation, ou Une ligne pour compacter une requête destinée à une chaîne dans du code ou à une recherche dans des journaux. Les commentaires SQL sont conservés dans le résultat.
Pourquoi ma requête SQL ne se formate-t-elle pas ? Corriger « Parse error: Unexpected »
Le formateur SQL lit la requête avec les règles du dialecte sélectionné, donc une syntaxe propre à une autre base de données provoque une erreur comme « Parse error: Unexpected … at line 1 column 8 ». Les identifiants entre backticks comme `order` relèvent de la syntaxe MySQL, MariaDB, BigQuery et Spark, et échouent avec PostgreSQL ou SQL Server. Les crochets comme [order] appartiennent à SQL Server et échouent avec MySQL. Choisissez le dialecte pour lequel la requête a été écrite, et l’erreur disparaît généralement.
Les paramètres dépendent aussi du dialecte. Un « ? » venant de JDBC ou d’un driver MySQL fonctionne en SQL standard, MySQL, PostgreSQL et SQLite, $1 fonctionne en PostgreSQL, et SQL Server attend des paramètres nommés comme @id : un « ? » y bloque donc le formateur. Les balises de template de dbt ou d’autres outils basés sur Jinja ne sont pas du SQL et provoquent une erreur d’analyse dès la première balise. Formatez plutôt la requête compilée.
Bonnes pratiques de style SQL pour des requêtes lisibles
Le formatage corrige la mise en page, et quelques habitudes facilitent la relecture des requêtes. Écrivez des JOIN … ON explicites au lieu de lister les tables séparées par des virgules dans FROM, donnez aux tables des alias courts et parlants comme u pour users et o pour orders, et nommez les colonnes dont vous avez besoin au lieu de SELECT *. Les expressions de table communes écrites avec WITH … AS découpent une longue requête en étapes nommées qui se lisent de haut en bas.
Gardez une seule configuration de formatage SQL par dépôt : même dialecte, même casse des mots-clés et même indentation, pour que reformater une requête n’ajoute jamais de bruit à la revue de code. Pour comparer deux versions d’une longue requête, formatez-les toutes les deux ici avec des réglages identiques, puis collez-les dans le Comparateur de textes. Sans cette étape, un saut de ligne déplacé apparaît comme une différence alors que la requête elle-même est identique.
Quelque chose ne fonctionne pas, ou un résultat semble faux ? Signaler un problème avec cet outil