Formater une requête SQL

Comment ça marche

Collez la requête dans le volet de gauche ; la version mise en forme apparaît aussitôt à droite. L’outil place les mots-clés principaux — SELECT, FROM, WHERE, GROUP BY, ORDER BY, JOIN — en début de ligne, met chaque colonne de la liste SELECT sur sa propre ligne et indente d’un cran les conditions AND et OR du WHERE ; les tables temporaires ouvertes par WITH (les CTE), les branches d’un CASE WHEN et les fonctions de fenêtrage comme ROW_NUMBER() OVER (PARTITION BY ...) reçoivent elles aussi leur propre niveau. Une requête de 340 caractères recopiée d’un journal devient, dès le collage, une mise en page qui montre ligne par ligne quelles tables sont jointes et quelles conditions s’appliquent. Indiquer la base d’origine rend le résultat plus juste : la conversion valeur::int de PostgreSQL, le TOP 10 et les noms entre [crochets] de SQL Server, les accents graves de MySQL sont alors lus selon les règles de ce dialecte. Si vous l’ignorez, laissez SQL standard. Le texte entre apostrophes, les noms entre guillemets ou crochets et les lignes de commentaire ne sont pas touchés. La ligne de résultat indique combien de lignes en sont devenues combien et quelles règles ont servi ; vous pouvez copier la sortie ou la télécharger en fichier .sql. L’option une ligne fait l’inverse : espaces superflus et retours à la ligne disparaissent, la requête tient sur une ligne — pour l’incorporer dans du code, la coller dans un champ qui n’accepte qu’une ligne ou la comparer à un journal. Les valeurs entre apostrophes y restent intactes ; les commentaires de ligne -- deviennent /* ... */, car sur une seule ligne -- mettrait tout le reste en commentaire et la requête cesserait de fonctionner.

Cet outil est aussi connu sous le nom de formater sql, sql formatter en ligne, mettre en forme sql, sql en une ligne.

Qu'est-ce que SQL ?

SQL (Structured Query Language) est le langage standard pour interroger les bases de données relationnelles et manipuler leurs données ; MySQL, PostgreSQL, SQL Server, Oracle et SQLite en parlent chacun un dialecte. Le cœur du langage est déclaratif : vous écrivez ce que vous voulez (quelles colonnes, de quelle table, sous quelle condition), et la base planifie comment le trouver. Les espaces et les retours à la ligne n'ont aucun sens pour SQL — une requête tassée sur une ligne et la même requête soigneusement indentée s'exécutent à l'identique ; la différence n'existe que pour l'humain qui lit. C'est cette différence que produit cet outil.

Qu'est-ce que Sous-requête (subquery) ?

Une sous-requête est un second SELECT incrusté entre parenthèses dans une requête ; la requête externe utilise son résultat comme une table ou comme une valeur unique. Pour trouver par exemple les salaires supérieurs à la moyenne, on écrit à droite de la condition WHERE un SELECT séparé qui calcule cette moyenne. Comme les sous-requêtes peuvent s'imbriquer, c'est la structure qui gêne le plus la lecture : sur une seule ligne, on perd de vue quelle parenthèse se ferme où. Le formateur fait entrer chaque sous-requête d'un cran et montre ces couches comme un escalier.

Qu'est-ce que Mot-clé (keyword) ?

Les mots-clés sont les mots propres de SQL : SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY. Ils construisent la grammaire du langage ; tout le reste est fait des noms que vous donnez — tables, colonnes, alias. SQL ne distinguant pas les majuscules des minuscules, les mots-clés fonctionnent quelle que soit leur écriture ; les écrire en majuscules est une convention de lisibilité qui sépare à l'œil les commandes des noms. Cet outil n'applique la conversion de casse qu'aux mots-clés ; l'écriture des noms que vous avez choisis reste intacte.

Ligne unique ou indentation ?

Les deux sens répondent à un vrai besoin. La forme indentée sert à lire : dans un éditeur comme SSMS, DBeaver ou pgAdmin, une longue requête montre ligne par ligne quelle table se joint à quoi. La ligne unique sert à transporter — pour incruster la requête dans une chaîne de code, la coller dans un champ de configuration qui n'accepte qu'une ligne ou comparer à l'œil deux requêtes, les retours à la ligne ne font que gêner.

En ramenant sur une ligne, le seul danger vient des commentaires de ligne. Un commentaire commençant par -- couvre tout jusqu'à la fin de la ligne ; une fois la requête aplatie, toutes les expressions qui suivent tombent dans le commentaire et la requête cesse silencieusement de fonctionner. Cet outil ne supprime pas le commentaire : il le convertit en bloc /* ... */ — votre note est conservée et la requête reste exécutable. Si le commentaire contient la séquence */, elle est écartée pour que le bloc ne se referme pas trop tôt.

Mettre en forme n'est pas valider

Cet outil n'exécute pas la requête et ne vérifie pas la syntaxe comme le ferait une base de données : un nom de colonne inexistant, une table mal orthographiée ou une condition de JOIN manquante restent tels quels dans la sortie mise en forme. L'apport est ailleurs — une fois la requête dépliée en lignes, une parenthèse en trop, une condition mal placée ou une virgule oubliée sautent aux yeux.

Son périmètre est volontairement étroit : l'outil est conçu pour des instructions SQL prises une à une. Plusieurs instructions séparées par des points-virgules sont espacées d'une ligne vide ; mais les corps de procédures stockées, les blocs BEGIN…END et les langages procéduraux propres à chaque base (PL/SQL, instructions de contrôle T-SQL) ne sont pas son affaire — sur ce genre de texte, le découpage en lignes peut ne pas sortir comme prévu.

Mots-clés en MAJUSCULES ou en minuscules ?

SQL est insensible à la casse : select et SELECT fonctionnent pareil. La majuscule est une convention installée pour distinguer à l'œil les commandes du langage des noms de tables et de colonnes ; les manuels et la documentation officielle la suivent en majorité, et si vous ne connaissez pas votre lecteur, c'est le choix sûr.

La minuscule a gagné du terrain ces dernières années, surtout dans les bases de code : les éditeurs colorent déjà les mots-clés, la majuscule a perdu son rôle distinctif, et la minuscule fatigue moins l'œil. L'essentiel est de tenir la même convention sur tout le projet ; l'option Ne pas toucher existe pour ne corriger que la disposition sans modifier l'écriture existante.

Que change le choix du dialecte ?

SQL n’est pas une langue unique mais une famille de langues très proches. Le noyau est partout le même, mais chaque base a ses écritures propres : PostgreSQL convertit avec valeur::int, SQL Server limite les lignes avec TOP 10 et entoure les noms de [crochets], MySQL emploie l’accent grave, et dans BigQuery un nom de table compte trois parties, comme `projet.jeu.table`.

Choisir le bon dialecte permet de reconnaître si ces écritures sont des noms ou des commandes. Un mauvais choix ne change rien à la plupart des requêtes, mais là où une telle écriture apparaît, le découpage en lignes peut surprendre. Si vous l’ignorez, laissez SQL standard : il connaît le noyau commun et met correctement en forme presque toutes les requêtes courantes. Si une requête ne peut pas être analysée avec le dialecte choisi, l’outil bascule discrètement sur sa propre mise en forme intégrée et le signale dans la ligne de résultat — vous n’êtes jamais laissé sans sortie.

Questions fréquentes

Comment mettre en forme une requête SQL ?

Collez la requête dans le panneau de gauche ; sa version avec mots-clés en début de ligne et sous-requêtes indentées se forme aussitôt à droite. Vous pouvez la copier ou la télécharger en fichier .sql.

Ma requête est-elle envoyée à un serveur ?

Non. La mise en forme se fait entièrement dans votre navigateur ; la requête, les noms de tables et les valeurs qu'elle contient ne partent vers aucun serveur. Vous pouvez coller sans crainte des conditions WHERE contenant de vraies données clients.

Les valeurs texte et les commentaires de la requête changent-ils ?

Non. Les valeurs entre apostrophes, les noms entre guillemets doubles ou crochets et les commentaires -- et /* */ sont préservés tels quels ; le changement de casse ne s'applique qu'aux mots-clés.

Comment ramener la requête sur une seule ligne ?

Choisissez l'option Ramener sur une ligne dans la liste du haut ; espaces superflus et retours à la ligne sont nettoyés et la requête apparaît sur une ligne à droite. Les valeurs entre apostrophes restent intactes ; les commentaires commençant par -- sont convertis en /* ... */, car sur une ligne unique un -- mettrait en commentaire tout ce qui le suit — cette conversion garde la requête exécutable.

Peut-on mettre en forme une procédure stockée ?

Le périmètre de l'outil est la requête prise isolément. Les blocs BEGIN…END et les instructions procédurales ne sont pas reconnus spécialement ; si vous collez un tel texte, la sortie reste exécutable mais le découpage en lignes peut ne pas correspondre à votre attente.

Pourquoi ma requête commençant par WITH (une CTE) n’était-elle pas correctement indentée ?

Elle l’est désormais. L’outil place chaque table temporaire ouverte par WITH à son propre niveau ; avec deux CTE imbriquées, le second bloc s’indente d’un cran de plus. De la même façon, chaque branche d’un CASE WHEN passe à la ligne et les fonctions de fenêtrage comme ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...) sont également déployées.

Je ne sais pas quel dialecte choisir. Que se passe-t-il ?

Rien de fâcheux : SQL standard est la valeur par défaut et met correctement en forme presque toutes les requêtes courantes. Le dialecte ne compte que là où apparaît une écriture propre à une base — la conversion :: de PostgreSQL, le TOP et les [crochets] de SQL Server. Si vous savez d’où vient la requête, choisissez-la dans la liste ; sinon, regardez la sortie et, si elle ne correspond pas à votre attente, changez de dialecte et réessayez.