Formateur/embellisseur SQL

Le Formateur/embellisseur SQL est un outil gratuit qui transforme du code SQL en une version plus lisible, avec une mise en forme cohérente.

Que change la mise en forme du SQL ?

La mise en forme modifie la présentation d'une requête afin de rendre ses clauses, ses expressions et ses structures imbriquées plus faciles à suivre. Elle ajoute généralement des sauts de ligne et des retraits autour d'éléments tels que les listes SELECT, les clauses JOIN, les conditions WHERE, les sous-requêtes et les expressions CASE.

La mise en forme ne devrait pas modifier le résultat attendu de la requête. Toutefois, les dialectes SQL diffèrent et une simple mise en forme ne permet pas de garantir qu'une instruction a conservé son sens. Vérifie le SQL généré avant de l'exécuter sur des données de production, en particulier s'il utilise des opérateurs propres à un fournisseur, des extensions procédurales ou des règles inhabituelles concernant les guillemets.

Un formateur est utile pour lire des requêtes écrites par d'autres personnes, contrôler du SQL généré, déboguer une longue instruction ou préparer du code pour une pull request. Une présentation cohérente facilite aussi la comparaison des modifications en réduisant les différences d'espacement sans rapport avec le fond.

Comment mettre en forme une requête SQL ?

Colle ou saisis l'instruction dans le champ SQL, puis envoie-la pour obtenir la version mise en forme dans SQL embelli. Le contenu est transmis au serveur via HTTPS pour être traité, mais il n'est pas stocké.

1. Copie l'instruction complète, y compris les expressions de table communes à conserver, puis vérifie les commentaires et l'éventuel point-virgule final dans le résultat.
2. Saisis-la dans le champ SQL. Dans la mesure du possible, évite de mettre en forme des fragments isolés.
3. Lis le résultat dans SQL embelli, en prêtant une attention particulière aux expressions imbriquées et à la syntaxe propre au dialecte utilisé.
4. Exécute l'instruction mise en forme dans un environnement de développement ou de préproduction adapté avant de la déployer.

Pour les travaux portant sur des bases de données sensibles, consulte la politique de ton organisation avant d'envoyer le texte d'une requête à un outil traité côté serveur. Supprime les mots de passe, les jetons d'accès, les données personnelles et les valeurs littérales confidentielles lorsqu'ils ne sont pas nécessaires à la compréhension de la requête.

Comment lire le SQL mis en forme ?

Suis les retraits et les limites entre les clauses, sans considérer la nouvelle présentation comme une preuve de validité de l'instruction. Les clauses SELECT, FROM, WHERE, GROUP BY et ORDER BY de premier niveau sont généralement plus faciles à distinguer lorsque chaque partie logique occupe sa propre ligne ou son propre niveau de retrait.

• Les sous-requêtes en retrait indiquent où le résultat d'une instruction interne est utilisé par une instruction externe.
• Les conditions alignées facilitent la vérification de la priorité entre AND et OR. Par défaut, AND reste prioritaire sur OR, tandis que les parenthèses déterminent toujours le regroupement logique.
• Les clauses JOIN séparées permettent de mieux voir quelle condition ON correspond à chaque table.
• Les listes SELECT développées aident à repérer les virgules manquantes, les colonnes dupliquées et les alias ambigus.
• Les branches CASE bien visibles permettent d'associer plus facilement les mots-clés WHEN, THEN, ELSE et END.

Les chaînes entre guillemets, les nombres, la ponctuation et les commentaires ont une signification en SQL. Examine-les au lieu de supposer qu'ils ne servent qu'à la présentation. Les caractères accentués ou non latins peuvent être valides dans les chaînes littérales et les identifiants entre guillemets, selon la base de données et son encodage de caractères.

Quelques exemples simples de mise en forme

Voici une requête compacte.

Entrée : SELECT id,name FROM customers WHERE active=1 ORDER BY name;

Une version lisible pourrait être présentée ainsi.

Sortie : SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

Une requête comportant une jointure bénéficie davantage des retraits.

Entrée : SELECT o.id,c.name FROM orders o JOIN customers c ON c.id=o.customer_id WHERE o.total>100;

Une sortie lisible pourrait placer SELECT, FROM, JOIN, ON et WHERE sur des lignes distinctes, tout en conservant la comparaison o.total > 100. L'emploi des majuscules, les espacements et l'emplacement des sauts de ligne varient selon les conventions de mise en forme. Considère donc ces exemples comme des propositions de présentation, et non comme une convention garantie.

La mise en forme peut-elle détecter les erreurs SQL ?

Non. Embellir du SQL ne revient pas à le valider avec l'analyseur syntaxique d'une base de données. Cet outil produit du SQL mis en forme. Il ne faut donc pas le considérer comme un vérificateur de syntaxe ou de schéma, ni comme un outil d'analyse du plan d'exécution.

Une présentation plus claire peut néanmoins faire ressortir des erreurs probables pendant la relecture. Il peut s'agir, par exemple, d'une virgule manquante dans une liste SELECT, de parenthèses non appariées, d'une chaîne entre guillemets non terminée, d'un JOIN dépourvu de la condition prévue ou d'une expression AND ou OR mal regroupée. Un mot réservé employé comme identifiant sans guillemets peut également devenir plus facile à repérer.

Certains problèmes ne peuvent pas être identifiés sans connaître la base de données cible. Une instruction acceptée par PostgreSQL peut nécessiter des modifications pour Microsoft SQL Server, MySQL, Oracle Database ou SQLite. Les tables absentes, les colonnes inconnues, les types de données incompatibles et les erreurs d'autorisation doivent généralement être diagnostiqués par le moteur de base de données ou par un outil de développement tenant compte du dialecte.

Quand la mise en forme du SQL est-elle inutile ?

La mise en forme est généralement superflue lorsque le SQL est déjà présenté de manière cohérente ou qu'il sera uniquement traité par une machine. Reformater des requêtes générées peut créer de nombreuses modifications inutiles dans le contrôle de version sans améliorer le générateur qui les a produites.

Ce n'est pas non plus forcément la bonne étape dans les situations suivantes :

• Un fichier de migration a été signé, associé à une somme de contrôle ou comparé octet par octet d'une autre manière.
• Une requête minifiée ou compacte est intégrée à un artefact soumis à une contrainte de taille et personne n'a besoin de la relire.
• La tâche immédiate concerne la validation, l'analyse du plan d'exécution ou l'optimisation des performances plutôt que la lisibilité.
• La requête contient des valeurs confidentielles que la politique de l'organisation interdit d'envoyer à un service traité côté serveur.

Pour appliquer de façon reproductible une mise en forme à l'ensemble d'un dépôt, un formateur en ligne de commande tenant compte du dialecte peut être plus adapté, car sa configuration peut être versionnée avec le code. Pour les charges utiles structurées d'une API qui contiennent du SQL, le Validateur et embellisseur JSON peut faciliter l'examen du JSON qui l'entoure. Le SQL lui-même doit néanmoins être traité avec un outil qui lui est propre.

Questions fréquentes

La mise en forme du SQL change-t-elle le comportement de NULL ?

Les espaces et les retraits ne modifient ni la logique à trois valeurs du SQL ni le comportement de NULL. Vérifie tout de même les expressions telles que column = NULL, qui nécessitent généralement IS NULL, car un formateur ne corrigera pas cette erreur sémantique.

Puis-je mettre en forme plusieurs instructions SQL à la fois ?

La prise en charge simultanée de plusieurs instructions SQL n'est pas documentée. Mets chaque instruction en forme séparément.

Puis-je laisser les commentaires dans le SQL envoyé ?

Les commentaires peuvent contenir des références de tickets, des noms d'hôtes internes, des informations sur des clients ou des notes d'exploitation, même lorsque le SQL exécutable ne contient aucune valeur littérale sensible. Vérifie les commentaires de ligne comme les blocs de commentaires avant d'envoyer le texte au serveur.

Faut-il écrire les mots-clés SQL en majuscules ou en minuscules ?

Les deux conventions sont généralement acceptables, car de nombreux moteurs de base de données ne tiennent pas compte de la casse des mots-clés sans guillemets. Respecte la convention utilisée dans le dépôt et sois prudent avec les identifiants entre guillemets, car certaines bases de données conservent leur casse ou font la distinction entre majuscules et minuscules.

Que faut-il vérifier avant d'exécuter la requête mise en forme ?

Confirme le dialecte de la base de données cible, examine les conditions WHERE et JOIN, puis vérifie les limites des transactions pour les instructions UPDATE, DELETE et celles qui modifient le schéma. Exécute d'abord les requêtes risquées dans une base de développement ou de préproduction, de préférence avec des données représentatives et des sauvegardes adaptées.