Formateur & Minificateur SQL

Formateur SQL - Formater, Minifier et Analyser sur 15 Dialectes

Un formateur, embellisseur et minifieur SQL puissant et sûr, compatible avec 15 dialectes — SQL Standard, MySQL, MariaDB, PostgreSQL, SQLite, T-SQL (SQL Server), Oracle PL/SQL, BigQuery, Snowflake, Redshift, DB2, Spark SQL, Trino/Presto, Hive et N1QL. Il propose un surlignage syntaxique, des mots-clés en majuscules, une indentation personnalisable, une minification consciente des chaînes et des commentaires qui ne corrompt jamais vos données, et un Contrôle de Sécurité intégré qui signale les instructions UPDATE/DELETE sans clause WHERE et les commandes destructrices TRUNCATE/DROP avant leur exécution. Idéal pour les développeurs de bases de données, les DBA et les ingénieurs backend qui relisent des scripts de migration ou de maintenance.

Quel est le style de formatage SQL standard ?

Il n'existe pas de standard officiel unique, mais la convention la plus adoptée suit le style de Joe Celko (de SQL for Smarties) : mots-clés en MAJUSCULES, identifiants en minuscules ou snake_case, une clause par ligne (SELECT, FROM, WHERE, etc.), colonnes indentées sous SELECT et jointures alignées sous FROM. Des outils modernes comme sqlfluff, sql-formatter et pgFormatter implémentent des variantes. La norme SQL ISO/IEC 9075 elle-même ne définit que la syntaxe et la sémantique, pas le style. La documentation de chaque éditeur suggère des lignes directrices : le wiki PostgreSQL a une page code style et le T-SQL de SQL Server dispose de guides de Microsoft Press. La cohérence au sein d'une équipe compte plus que le style spécifique choisi.

Pourquoi utiliser des MAJUSCULES pour les mots-clés SQL ?

Les mots-clés en majuscules (SELECT, FROM, WHERE, JOIN) séparent visuellement la syntaxe SQL des identifiants définis par l'utilisateur (noms de tables et colonnes), rendant les requêtes lisibles en un coup d'œil. La convention est née dans les mainframes des années 1970 où les cartes perforées utilisaient déjà tout en majuscules. Les parseurs SQL modernes sont insensibles à la casse pour les mots-clés selon la norme ISO 9075, donc `select` fonctionne identiquement à `SELECT`. Certaines équipes préfèrent désormais les minuscules pour la vitesse de frappe et l'esthétique moderne — la documentation Carbon (IBM) et l'API Stripe utilisent les minuscules. Des outils comme sqlfluff permettent l'un ou l'autre via `--rules L030`. Le choix est purement stylistique ; choisissez-en un et appliquez-le de manière cohérente.

Comment formater les JOIN pour la lisibilité ?

Chaque JOIN va sur sa propre ligne, avec la clause ON indentée ou sur la ligne suivante. Le style moderne aligne les JOIN sous FROM et regroupe les conditions verticalement :
```
SELECT u.name, o.total
FROM users AS u
JOIN orders AS o ON o.user_id = u.id
LEFT JOIN profiles AS p ON p.user_id = u.id
WHERE o.created_at > '2024-01-01';
```
La syntaxe JOIN explicite (la norme ANSI SQL-92) est préférée au FROM avec virgules implicites car elle sépare proprement les conditions de jointure des filtres et empêche les produits cartésiens accidentels. Les plans EXPLAIN ANALYZE de PostgreSQL optimisent les deux formes identiquement, mais la différence de lisibilité s'accumule dans les requêtes à 5+ tables.

Qu'est-ce que la minification SQL et est-ce utile ?

La minification SQL supprime espaces, commentaires et sauts de ligne inutiles pour réduire la taille de la chaîne de requête. Utile pour intégrer du SQL dans du code JavaScript/TypeScript expédié aux clients, dans des paramètres d'URL pour des outils d'analytics ou dans des charges JSON où chaque octet compte. Des outils comme `sql-minifier-cli` et `sqlmin` s'en chargent. Avertissements : le SQL minifié est difficile à déboguer et relire, et la plupart des serveurs de base de données le parsent identiquement — aucun gain de performance à l'exécution. Les systèmes de build modernes (Vite, Webpack) minifient souvent le SQL embarqué automatiquement. Conservez le SQL source formaté pour les humains, minifiez uniquement au moment du build pour la production.

Comment empêcher l'injection SQL dans des requêtes formatées ?

Utilisez toujours des requêtes paramétrées (prepared statements) plutôt que de la concaténation de chaînes : `SELECT * FROM users WHERE id = $1` avec `$1` lié comme paramètre, jamais `SELECT * FROM users WHERE id = ' + userId`. La OWASP SQL Injection Prevention Cheat Sheet (2023) et CWE-89 listent cela comme défense primaire. Chaque SDK moderne le prend en charge : `cursor.execute(sql, (id,))` de psycopg, `PreparedStatement.setInt(1, id)` de JDBC, `client.query(text, values)` du pg Node.js. Le style de formatage n'a aucun impact sécurité, mais n'incluez jamais l'entrée utilisateur directement dans les chaînes SQL. Les procédures stockées et les ORM ajoutent des couches de défense supplémentaires, mais la paramétrisation correcte est la fondation.

Que sont les Common Table Expressions (CTE) et comment les formater ?

Les CTE sont des sous-requêtes nommées définies avec le mot-clé WITH, introduites dans ISO SQL:1999 et prises en charge par PostgreSQL, MySQL 8.0+, SQL Server et Oracle. Elles améliorent la lisibilité en découpant des requêtes complexes en étapes nommées et séquentielles. Formatez chaque CTE dans son propre bloc, séparées par des lignes vides :
```
WITH active_users AS (
SELECT id, name FROM users WHERE last_login > NOW() - INTERVAL '30 days'
),
order_totals AS (
SELECT user_id, SUM(amount) AS total FROM orders GROUP BY user_id
)
SELECT u.name, COALESCE(o.total, 0) AS total
FROM active_users u
LEFT JOIN order_totals o ON o.user_id = u.id;
```
Les CTE récursives utilisent `WITH RECURSIVE` et nécessitent des conditions de terminaison soigneuses pour éviter des boucles infinies.

Les noms de tables et colonnes doivent-ils utiliser snake_case ou PascalCase ?

La plupart des conventions de bases de données privilégient snake_case (`user_id`, `created_at`) car tous les principaux moteurs convertissent les identifiants non guillemetés en minuscules ou en majuscules en interne, rendant le mélange de casses fragile. PostgreSQL convertit en minuscules ; Oracle et DB2 en majuscules. Les identifiants PascalCase ou camelCase nécessitent des guillemets doubles (`"UserId"`) pour préserver la casse, ce qui est verbeux et source d'erreurs. snake_case est le standard de fait dans les écosystèmes PostgreSQL, MySQL et SQLite. PascalCase est plus courant dans SQL Server (T-SQL), où le moteur préserve la casse dans les métadonnées. Des ORM comme Hibernate et Sequelize fournissent une conversion automatique (camelCase dans le code, snake_case en DB) via des mappeurs de noms de colonnes.

Peut-il formater spécifiquement BigQuery, Snowflake ou T-SQL ?

Oui. Le menu Dialecte prend en charge 15 grammaires et chacune modifie la manière dont le formateur traite les mots-clés, opérateurs et guillemets. Choisissez **bigquery** pour les identifiants `projet.dataset.table` entre accents graves, la syntaxe array/struct et les fonctions STANDARD SQL ; **snowflake** pour son opérateur de cast `::`, l'accès par chemin semi-structuré `:` et FLATTEN ; **tsql** pour les identifiants `[entre crochets]` de SQL Server, TOP et les `@variables` ; **postgresql** pour les marqueurs `$1`, les casts `::type` et les chaînes en dollar-quoting. Également pris en charge : MySQL, MariaDB, SQLite, Oracle PL/SQL, Redshift, DB2, Spark SQL, Trino/Presto, Hive et N1QL (Couchbase). Si vous choisissez le mauvais dialecte, la sortie reste valide mais peut ne pas aligner idéalement la syntaxe propre au moteur ; faites donc correspondre le menu à votre base de données cible pour un résultat optimal.

La minification conserve-t-elle mes données de chaîne intactes ?

Oui. Le minifieur repose sur un tokeniseur : il parcourt la requête et ignore les littéraux entre guillemets simples, doubles et accents graves ainsi que les commentaires `--` et `/* */`, en compressant les espaces et supprimant les commentaires UNIQUEMENT dans les régions de code environnantes. Ainsi, une valeur comme `'John Doe'` conserve son double espace, `'50% -- off'` n'est pas tronqué au `--`, et `'a/*b*/c'` est préservé tel quel. Les minifieurs naïfs antérieurs qui exécutent un remplacement `\s+` global modifient silencieusement la sémantique de la requête — pas cet outil. Lancez Minifier ou Formater et le badge **Contrôle de Sécurité** au-dessus de la sortie indique aussi combien d'instructions ont été analysées, pour confirmer que l'outil a bien lu votre script.

Quels outils formatent SQL automatiquement ?

Outils principaux en 2025 : **sqlfluff** (Python, multi-dialecte, opinionnée, utilisé par dbt) — le plus populaire, lint et fix ; **pg_format** (Perl, focalisé PostgreSQL, rapide) ; **sql-formatter** (JavaScript, multi-dialecte) ; **sqlfmt** (de Tylerb, basé Go, opinionné comme Black) ; **Poor SQL** (en ligne) ; et des plugins IDE pour VSCode (SQLTools), DataGrip et SQL Server Management Studio. L'adoption de sqlfluff par dbt a standardisé le style SQL dans la communauté analytique. L'intégration CI est directe : `sqlfluff lint models/` et `sqlfluff fix --force models/` dans GitHub Actions ou GitLab CI avant le merge. Configurez le dialecte dans `.sqlfluff` pour correspondre à votre base de données (postgres, snowflake, bigquery, mysql, etc.).

Fonctionnalités clés

• Formater du SQL avec une indentation personnalisable
• Mettre les mots-clés en majuscules pour plus de lisibilité
• Minification sûre qui préserve les chaînes et marqueurs de commentaire entre guillemets
• Contrôle de Sécurité signalant UPDATE/DELETE sans WHERE et TRUNCATE/DROP
• Compteur d'instructions pour les scripts multi-requêtes
• Surlignage des mots-clés, fonctions, chaînes et nombres
• Statistiques en temps réel
• Copier / Télécharger / Téléverser vos requêtes
• Mode sombre
• 15 dialectes : MySQL, MariaDB, PostgreSQL, SQLite, T-SQL, Oracle PL/SQL, BigQuery, Snowflake, Redshift, DB2, Spark, Trino/Presto, Hive, N1QL
• Traitement 100 % côté client, aucune exécution SQL
• Interface responsive adaptée au mobile