Formateur et Embellisseur SQL

Non. Le formateur ne modifie que les espaces blancs, l'indentation et (optionnellement) la casse des lettres des mots-clés. La structure logique — noms de tables, noms de colonnes, conditions, jointures, expressions — n'est jamais altérée. Une requête formatée produit exactement le même résultat que l'originale lorsqu'elle est exécutée sur une base de données. Vous pouvez formater en toute sécurité puis copier le code vers votre application sans aucun risque d'introduire des changements logiques.

Oui. Les commentaires SQL sur une seule ligne (-- commentaire jusqu'à la fin de la ligne) et les commentaires par blocs (/* commentaire multi-ligne */) sont reconnus et préservés dans le résultat formaté. Les littéraux de chaînes (valeurs entre guillemets simples), les identifiants cités (accent grave ou doubles guillemets selon le dialecte) et les littéraux numériques sont tous gérés correctement — ils ne sont jamais coupés sur plusieurs lignes ni modifiés pendant le formatage. Les citations imbriquées et les caractères échappés à l'intérieur des chaînes sont également préservés.

Il n'y a pas d'exigence standard SQL — les mots-clés fonctionnent dans n'importe quelle casse dans la plupart des bases de données. Cependant, l'utilisation de mots-clés en majuscules (SELECT, FROM, WHERE, JOIN) est la convention largement dominante dans le code SQL pour une raison clé : la lisibilité. Lorsque vous parcourez une requête SQL formatée, les mots-clés en majuscules se distinguent des noms de tables/colonnes en minuscules, rendant la structure de la requête instantanément visible. Cet outil utilise par défaut les mots-clés en majuscules, ce qui est la convention dans la plupart des guides de style SQL incluant ceux de Google, GitLab et Kickstarter.

Oui, pour des besoins de formatage général. La syntaxe SQL de base (SELECT, JOIN, WHERE, etc.) est standard sur MySQL, PostgreSQL, SQLite, SQL Server et Oracle. La syntaxe spécifique à la base de données est généralement acceptée mais peut ne pas être formatée parfaitement — par exemple, le typage spécifique à PostgreSQL ::, les fonctions spécifiques au T-SQL de SQL Server, ou la syntaxe LIMIT/OFFSET de MySQL. Si vous voyez un formatage inattendu dans un code spécifique à un dialecte, la logique reste correcte — seule la présentation de l'indentation peut varier.

Le SQL non formaté est une source courante de bugs oubliés lors des revues de code. Lorsqu'une requête se trouve sur une seule longue ligne, il est facile de rater une condition JOIN manquante (causant un produit cartésien), une clause WHERE omise accidentellement (affectant toutes les lignes) ou une priorité incorrecte dans les conditions AND/OR. Le SQL formaté place chaque clause et condition sur sa propre ligne, rendant les erreurs structurelles visuellement évidentes. De nombreuses équipes exigent que le SQL soit formaté avant la revue pour cette raison précise.

Le SQL multi-instructions de base (plusieurs instructions SELECT ou INSERT séparées par des points-virgules) est géré — chaque instruction est formatée indépendamment. Cependant, les procédures stockées, PL/pgSQL, les blocs T-SQL avec BEGIN/END et le SQL procédural complexe peuvent ne pas se formater proprement car le formateur se concentre sur les instructions DML/DDL standards. Pour les procédures stockées, essayez de formater les instructions individuelles à l'intérieur du corps de la procédure plutôt que la définition complète de la procédure.

Non. Tout le formatage s'exécute dans votre navigateur en utilisant JavaScript. Vos requêtes SQL, y compris les noms de tables, les noms de colonnes, les valeurs de données ou les chaînes de connexion dans la requête, ne quittent jamais votre appareil. Cela permet de formater en toute sécurité des requêtes de production contenant des références de données réelles ou des informations de schéma propriétaires.