Formateur & Minificateur SQL

Formatez, embellissez et minifiez vos requêtes SQL avec coloration syntaxique et mots-clés en majuscules. MySQL, PostgreSQL, SQL Server, Oracle.

Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons tout

Formateur SQL - Formater et embellir des requêtes SQL

Un formateur SQL puissant pour nettoyer, embellir et minifier vos requêtes. Il propose un surlignage syntaxique, des majuscules optionnelles sur les mots-clés et une indentation personnalisable. Idéal pour les développeurs de bases de données et les administrateurs SQL.

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.

Formateur & Minificateur SQL — Formatez, embellissez et minifiez vos requêtes SQL avec coloration syntaxique et mots-clés en majuscules. MySQL, Postgre — **Formateur & Minificateur SQL**

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.

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.).