La pire question que j'aie jamais dû examiner était de 340 lignes sur une seule pensée logique : un rapport de revenus pour un SaaS Laravel, rédigé comme un DB::select() RAW String, construit sur huit mois par trois développeurs qui avaient chacun une idée différente de la capitalisation et aucune sur les sauts de ligne. quelque part dans ce mur de texte, un LEFT JOIN était devenu tranquillement un INNER JOIN Lors d'une refactorisation, et les clients avec zéro commande ont disparu du rapport. Le bug était un mot. Le constater a pris un jour et demi, non pas parce que la logique était difficile, mais parce que la requête était illisible, et le code illisible masque ses bogues à la vue de tous.
Voici le problème de SQL : la base de données ne se soucie pas de votre mise en forme. L'analyseur lit select id,name from users where active=1 et SELECT id, name FROM users WHERE active = 1 Comme la même instruction, produit le même plan d'exécution, renvoie les mêmes lignes dans le même temps. Le formatage de SQL est uniquement destiné aux humains - ce qui explique exactement la raison pour laquelle cela en vaut la peine, car les humains sont ceux qui le révisent, le débogent à 2 heures du matin et héritent de trois emplois plus tard. Une requête que vous ne pouvez pas parcourir est une requête que vous ne pouvez pas vérifier.
un Formateur SQL Transforme toute requête - collée à partir d'un journal, la sortie de débogage d'un ORM, un message Slack d'un collègue, une procédure stockée héritée - en un SQL révisable de manière cohérente, systématiquement mis en place, en un clic. Celui sur Toolz.dev s'exécute entièrement dans votre navigateur, ce qui compte plus pour SQL que pour presque tous les autres textes que vous collez dans un outil en ligne, car les requêtes de production transportent votre schéma et parfois vos données.
Ce guide explique comment l'utiliser, les conventions de mise en forme qui comptent réellement (cas de mots clés, indentation et guerre des virgules éternelles) et les flux de travail où un formateur se rentabilise quotidiennement.
tl;dr : Collez toute requête dans Formateur SQL Toolz.dev Et revenez régulièrement en retrait, SQL systématique, systématique, gratuit, côté client, sans inscription. Le formatage ne change jamais ce qu'une requête fait ou à quelle vitesse elle s'exécute ; il change si un humain peut la vérifier. Conventions à adopter : mots-clés en majuscules, une clause par ligne, retrait sous chaque clause, et choisissez un style de virgule et arrêtez de vous argumenter. associez-le à la Formateur JSON Pour la couche d'API au-dessus de votre base de données et la Outil de diff de texte Pour comparer deux versions d'une requête.
Principales caractéristiques
Indentation cohérente en un clic
Le cœur du formateur : chaque clause majeure — SELECT, FROM, WHERE, GROUP BY, ORDER BY — Démarre sa propre ligne, avec des colonnes, des conditions et des jointures en retrait. Il s'agit de la "rivière" de la structure expérimentée. Les lecteurs SQL numérisés par : l'œil parcourt les mots-clés de la clause de lecture du bord gauche, puis plonge dans la clause. Une requête formatée en 60 lignes avec une structure claire plus vite qu'un non formaté à 6 lignes, car la structure fait la moitié de la lecture pour vous. Mon histoire d'horreur de 340 lignes aurait été une critique de vingt minutes avec cette forme - le type de jointure modifiée serait resté seul sur sa propre ligne, visiblement erroné.
Normalisation de cas de mots clés
SELECT contre select N'importe quelle base de données n'a vraiment aucune importance - les mots clés SQL sont insensibles à la casse selon la norme, et chaque dialecte les honore. Cela compte énormément pour une base de code, car le boîtier mixte est un bruit visuel qui rend les requêtes structurellement identiques différentes. Les mots clés en majuscules sont la convention plus ancienne, datant d'éditeurs sans mise en évidence de syntaxe, où SELECT en majuscules Était la mise en évidence. J'écris toujours en majuscules - les mots-clés apparaissent sur les identifiants minuscules et survivent à tous les contextes qui mettent en évidence la mise en évidence : journaux, diffs, e-mail en texte brut, sortie du terminal. Le formateur se normalise à la convention que vous avez choisie, de sorte qu'une base de code écrite par cinq personnes lit comme si elle avait été écrite par une seule.
Gère ORM et log de sortie
Les requêtes qui ont le plus besoin de formatage sont celles dont aucun humain n'a écrit : la sortie eloquent et activeRecord, doctrine, est générée, les monstres unifax dans votre journal de requêtes lentes. La sortie ORM arrive en une seule ligne avec des alias générés par la machine (t0, t1, laravel_reserved_0), et le lire brut est la façon dont vous avez des maux de tête. Mon utilisation la plus fréquente du formateur : récupérer la requête du journal de requête ou du télescope de Laravel, le formater et voir ce que l'ORM a décidé de faire - ce qui est la première étape de chaque "pourquoi cet endpoint est-il lent" d'enquête, juste avant EXPLAIN.
Tolérance multi-dialectale
SQL Real-World est une famille de dialectes : les identifiants de MySQL, les doubles citations et les identifiants de PostgreSQL :: Casts, crochets carrés de SQL Server et TOP, sqlite est facile à vivre. Un formateur utile les gère tous sans vous demander de déclarer d'abord un dialecte, en préservant la syntaxe spécifique au dialecte plutôt que la "corriger". Le standard ANSI/ISO SQL (ISO/IEC 9075) définit le tronc commun, mais personne n'écrit de SQL standard pur dans la pratique, et un formateur qui ne parle que le standard s'étoufferait au premier backtick.
Préserve la sémantique, garantie
Cela vaut la peine d'être explicitement indiqué parce que c'est la peur qui arrête les gens : le formatage ne peut pas changer les résultats. L'espace blanc et le cas des mots clés ne sont pas sémantiques en SQL, la seule mise en garde historique étant que Littéraux de chaînes sont comparés sensibles à la casse ou non en fonction de votre collation, et un formateur ne touche jamais l'intérieur de vos chaînes de devis. La sortie est la même instruction, octet pour octets où octets comptent. EXPLAIN Sur les deux versions si vous voulez le voir : plans identiques.
Côté client, ce qui compte en fait ici
SQL est la catégorie de texte la plus sensible qui est régulièrement collée dans les outils en ligne. Les requêtes révèlent votre schéma (noms de table, noms de colonne, relations) et requêtes copiées à partir de journaux contenant fréquemment des valeurs littérales : WHERE Clauses, plages d'ID, parfois quelque chose qui n'aurait jamais dû être dans une chaîne de requête. le Formateur Toolz.dev Tout traite dans votre navigateur, rien n'est transmis. Pour SQL, j'appellerais spécifiquement le traitement côté client d'une exigence, pas une fonctionnalité - vérifiez-la dans l'onglet Réseau, puis détendez-vous.
Comment utiliser le formateur SQL
Étape 1 : Capturez la requête
Copiez le SQL à partir de sa source : votre fichier de migration, une procédure stockée, la sortie de débogage de l'ORM (DB::listen() ou télescope à Laravel, ActiveRecord::Base.logger dans Rails), le journal de requêtes lente ou l'onglet de requête de votre outil APM. S'il provient d'un journal, il peut avoir échappé aux guillemets ou aux espaces réservés de paramètres (?, $1) — C'est bien, les formateurs gèrent les espaces réservés, et les voir clairement est souvent le point.
Étape 2 : Coller et formater
Ouvrez le Formateur SQL, coller et la version formatée s'affiche. Pas de cérémonie de dialecte, aucune configuration requise pour obtenir un bon défaut. Si votre requête comprend plusieurs instructions séparées par des points-virgules, elles sont formatées en tant que déclarations distinctes, utiles pour lire l'ensemble des scripts de migration.
Étape 3 : Lisez-le comme un critique
Maintenant, faites la chose que le formatage existe pour : scannez le bord gauche. Quelles tables sont jointes et avec quels types de jointure ? fait le WHERE ont les conditions que vous attendez - et sont-elles AND/OR Les regroupements ont été mis en place de la façon dont vous opinion Ils se regroupent ? (Précédents de l'opérateur dans les mises en place AND avant OR, et les mélanges non parenthèses des deux sont la deuxième source de bogues que je vois dans la revue, juste après de mauvais types de jointure.) Formaté SQL rend les deux erreurs visibles en quelques secondes.
Étape 4 : Copiez-le en arrière - de manière sélective
Pour les requêtes en tête de votre base de code, copiez la version formatée dans la migration, le ->select() expression brute, le .sql fichier. Pour le débogage unique, ne vous embêtez pas à aller au retour ; la copie formatée a servi son objectif au moment où vous l'avez lu. un endroit non Pour coller le SQL au format : de retour dans les systèmes qui stockent les requêtes en tant que chaînes de configuration où l'outillage de diff de quelqu'un affichera désormais un mur de changements d'espace blanc. Format de lecture Toujours ; Reformater les requêtes stockées uniquement lorsque vous êtes prêt à posséder le diff.
Étape 5 : Normaliser la convention d'équipe
La plus grande valeur du formateur est la composition : choisissez les conventions que vous pouvez automatiser - le cas des mots clés et la largeur d'indentation sont les deux contrôles de ce formateur directement - formatez tout ce qui est nouveau sur le chemin de la base de code et la friction de révision SQL chute définitivement. Notez le choix dans votre guide de contribution. La convention spécifique choisie est beaucoup moins importante que tout le monde utilisant la même chose - une phrase qui est vraie pour chaque débat de mise en forme dans les logiciels et croyait par approximativement personne au milieu du débat.
Plongée approfondie technique : les conventions qui valent la peine d'avoir des avis sur
Coffret de mots clés. Les mots clés en majuscules, les identifiants minuscules sont la convention dominante et ma recommandation. L'argument n'est pas la tradition, c'est la robustesse. La mise en évidence de la syntaxe disparaît dans les journaux, les terminaux, les commentaires de révision de code et les réponses de la pile de dépassements de la pile, les mots clés en majuscule mettent en évidence ce qui se déplace avec le texte. Le contre-argument (en bas de tout, laissez l'éditeur en surbrillance) est cohérent et j'ai travaillé dans des bases de code qui l'utilisaient avec bonheur. Ce qui n'est pas cohérent, c'est le mélange, ce que vous obtenez sans un formateur qui applique le choix.
Une clause par ligne, contenu en retrait. La règle structurelle avec le plus grand gain. SELECT Démarre une ligne, ses colonnes sont en retrait en dessous (ou sur la même ligne si courtes). chacun JOIN obtient sa propre ligne avec son ON Condition visible — Les conditions de jonction masquées au milieu de la ligne médiane sont celles où les bogues de connexion erronée se cachent. WHERE Les conditions empilent une par ligne, alignées, avec AND/OR Mener chaque ligne de sorte que la structure logique se lit verticalement. Lorsqu'une requête est lue comme une colonne, une condition manquante est visible sous la forme d'une Ecart dans un modèle, dont les yeux humains sont exceptionnellement bons pour les repérages.
La guerre des virgules. Les virgules de fin (après chaque colonne) sont lus naturellement ; les virgules de tête (avant chaque colonne, au début de la ligne) rendent la ponctuation structurelle :
-- Trailing (most common)
SELECT
u.id,
u.email,
o.total
-- Leading (the DBA classic)
SELECT
u.id
, u.email
, o.total
Les principaux défenseurs des virgules ont deux points vraiment bons : commenter une ligne, à l'exception de la première, ne casse jamais la déclaration, et une virgule manquante est instantanément visible sur la marge de gauche. Les défenseurs des virgules de fuite en ont un : il ressemble à toutes les autres langues que vous écrivez. J'écris des virgules de fin et je me suis senti mal à ce sujet, mais notez que SQL, contrairement à JavaScript ou Python moderne, le fait non Pardonnez une virgule qui pend après la dernière chronique, c'est pourquoi ce débat existe et pourquoi le style principal refuse de mourir dans les cercles DBA. Divulgation complète : le formateur Toolz.dev prend le côté traditionnel et émet des virgules de fuite. Il n'a pas de mode de virgule de tête, donc si vous êtes un magasin de leader engagé, il s'agit de la seule convention qu'il ne reformatera pas pour vous. Choisissez un style de maison, appliquez-le de manière cohérente et passez à autre chose.
Ce que le formatage ne fait pas. Il n'est pas optimisé. un formaté SELECT * À travers une jointure de cinq tables, il y a un problème de performances magnifiquement en retrait. Le formatage est le conditionner Pour une optimisation, vous ne pouvez pas raisonner une requête que vous ne pouvez pas lire, mais le raisonnement nécessite toujours EXPLAIN, la connaissance de l'index et la connaissance de la forme de vos données. Je pense que le pipeline est : formater, lire, EXPLAIN, puis optimisez. Sauter la première étape ne vous rend pas plus rapide, cela ralentit les étapes deux à quatre. La même discipline applique une couche vers le haut à l'API, c'est pourquoi le Guide de formatage JSON fait un argument structurellement identique sur les charges utiles.
Les commentaires survivent. Contrairement à la minification, le formatage préserve les commentaires — -- Commentaires en ligne et /* */ Les blocs passent intacts. Utilisez-les. un -- deliberately LEFT JOIN: include customers with no orders Commentaire ci-dessus Une jointure est l'assurance contre les bugs la moins chère jamais écrite, et c'est le commentaire dont mon histoire d'horreur de 340 lignes avait besoin.
Cas d'utilisation courants
Examen du code
SQL non formaté dans une demande d'extraction est un examen qui ne se produira pas - les yeux du critique glissent de toute façon sur le mur de texte et les terres d'approbation. Formatage de la requête avant l'ouverture du PR est une courtoisie de base avec un gain mesurable : les types de jointures, les groupes de conditions et les listes de colonnes deviennent visibles individuellement, ce qui signifie qu'ils deviennent individuellement révisables. Chaque bogue SQL authentique que j'ai attrapé en revue - la mauvaise jointure, la non parenthèse OR, le DELETE manquer la moitié de son WHERE Clause — J'ai attrapé parce que la requête était suffisamment formatée pour lire ligne par ligne.
Déboguer les requêtes générées par ORM
Les ORM sont merveilleux jusqu'à ce que le point de terminaison soit lent, auquel cas vous devez voir le SQL réel - et la sortie ORM est toujours une ligne dense. Formatez-le et l'histoire apparaît : le n+1 qui a manqué de charger, la définition de la relation ajoutée en silence, la ORDER BY sur une colonne non indexée. Dans le travail de Laravel, il s'agit d'un rituel plusieurs fois hebdomadaire : télescope, copie, format, Wince, corrigez le code éloquent, répétez. Le formateur ne diagnostique rien lui-même, il rend la requête suffisamment lisible pour que vous peut.
Archéologie sur les requêtes héritées
Chaque système de longue durée a eux : la procédure stockée de 2015, la vue de rapports que personne n'ose toucher, la requête intégrée dans un fichier de configuration avec la mise en forme de l'auteur d'origine (c'est-à-dire aucune). Avant de modifier le SQL hérité, formatez-le et lisez-le de bout en bout - vous trouverez régulièrement des conditions qui ne peuvent jamais être vraies, se joint à des tables qui ne reçoivent plus d'écritures, et la logique des hypothèses de l'équipe actuelle est en contradiction. Le formatage d'abord transforme "la requête héritée effrayante" en "interrogation longue mais lisible", ce qui est un problème différent et meilleur.
Comparaison des versions de requête
Lorsqu'un rapport change d'un rapport à l'autre, la question est "ce qui a changé dans la requête", et la réponse nécessite de différencier deux versions, ce qui ne fonctionne que si les deux sont formatés de la même manière. Formatez les deux avec les mêmes paramètres, puis exécutez-les via le Outil de diff de texte: Le bruit disparaît et les deux lignes modifiées sont seules. Cette séquence exacte a finalement trouvé mon bogue de jointure interne. je le fais maintenant avant Le jour et demi de confusion plutôt qu'après.
Enseignement et documentation
SQL dans les didacticiels, les runbooks et les documents internes est lu beaucoup plus de fois qu'il n'est écrit, par des lecteurs moins familiers avec le schéma que l'auteur. Les exemples formatés avec des mots-clés en majuscules et une structure à un concept par ligne sont considérablement plus faciles à apprendre - la structure enseigne à côté du contenu. Lorsque j'écris de la documentation avec des requêtes intégrées, tout le monde parcourt le formateur en premier ; SQL non formaté dans Docs indique au lecteur que l'auteur ne s'attendait pas à ce que quelqu'un le lise réellement.
Conventions de formatage comparées
| Choix de convention | Option un | Option B | mon avis |
|---|---|---|---|
| Cas de mot-clé | SELECT (majuscule) |
select (minuscule) |
Majuscule — Survit aux contextes sans mettre en évidence |
| Identifiant | serpent_case | Correspondance des définitions de table | Définitions de correspondance ; ne combattez jamais le schéma |
| virgule | Suivre (id,) |
diriger (, id) |
À la fin, mais diriger est défendable - choisissez-en un |
| disposition des clauses | Une clause par ligne | Ligne unique compacte | Un par ligne pour tout ce qui a été trivial |
AND/OR implantation |
Menant chaque ligne de condition | Ligne précédente | Leading — La logique se lit verticalement |
| Conditions de jon | ON sur sa propre ligne ou en ligne avec JOIN |
Ligne médiane enterrée | Visible avec la jointure, toujours |
| Largeur de retrait | 2 espaces | 4 espaces | Soit ; SQL n'imbrique pas moins que JSON, donc 4 est bien ici |
Aucune de ces lignes n'a de mauvaise réponse, et c'est précisément le piège - parce que chaque option est défendable, les équipes les re-contentent pour toujours, à moins qu'un formateur ne fasse la décision mécanique. Le coup gagnant est ennuyeux : choisissez, configurez, formatez, et passez le temps d'argument récupéré sur les éléments qui affectent le plan d'exécution. Pour le reste de la boîte à outils quotidienne autour de celle-ci, consultez le Guide des outils de codage Et le plus large Boîte à outils pour les développeurs Web.
FAQ
Que fait un formateur SQL ?
Un formateur SQL réécrit les espaces blancs, les sauts de ligne et les mots clés dans une structure cohérente et lisible - chaque clause sur sa propre ligne, conditions et colonnes en retrait, mots-clés normalisés à un cas. La signification de l'instruction n'est pas modifiée : les analyseurs SQL ignorent entièrement le formatage, de sorte que la requête formatée renvoie des résultats identiques avec un plan d'exécution identique. Le changement est purement pour les humains qui examinent, déboguer et maintenir la requête.
Le formatage de SQL modifie-t-il les performances de la requête ?
non . Les espaces blancs et les mots-clés ne sont pas sémantiques en SQL. La base de données analyse les deux versions dans la même représentation interne et produit le même plan d'exécution que vous pouvez vérifier en exécutant EXPLAIN sur chacun. Le formatage est la condition préalable au travail de performance plutôt que de la performance. Vous ne pouvez pas raisonner les index et l'ordre de jointure dans une requête que vous ne pouvez pas lire.
Les mots clés SQL doivent-ils être en majuscules ou en minuscules ?
Les deux sont valides - les mots clés SQL sont insensibles à la casse selon la norme - il s'agit donc d'une convention de lisibilité, et non d'une règle d'exactitude. Mots-clés en majusculesSELECT, FROM, WHERE) restent le choix le plus courant car ils agissent comme des mises en évidence intégrées dans des contextes qui dénudent les couleurs : journaux, diffs, terminaux et messages en texte brut. Quel que soit votre choix, la cohérence dans la base de code compte bien plus que le choix lui-même.
Quelles sont les virgules de pointe dans SQL et pourquoi les gens les utilisent-ils ?
Le style de la virgule en tête place la virgule au début de chaque ligne de colonne (, email) au lieu de la fin du précédent. Les défenseurs de leur propos aiment cela parce que commenter une colonne, sauf la première, ne produit jamais d'erreur de syntaxe, et les virgules manquantes sont instantanément visibles à la marge de gauche - de vrais avantages, car SQL ne tolère pas une virgule pendante après la dernière colonne comme le fait le Javascript moderne. Les virgules de suivi restent plus courantes, soit fonctionne si elles sont appliquées de manière cohérente.
Puis-je formater SQL généré par un ORM comme Eloquent ou ActiveRecord ?
Oui, et c'est l'une des meilleures utilisations d'un formateur - la sortie de débogage d'ORM arrive sous la forme d'une seule ligne dense avec des alias générés par la machine, et la formater est la première étape de diagnostic des terminaux lents et des problèmes de N+1. Capturez la requête à partir de votre journalisation ORM (télescope Laravel, journaux Active Record), collez-la dans le Formateur SQL, et lisez ce que l'ORM a réellement construit avant d'atteindre EXPLAIN.
Le formateur fonctionne-t-il avec la syntaxe MySQL, PostgreSQL et SQL Server ?
Oui — Les formateurs pratiques gèrent les principaux dialectes, qui permettent de conserver MySQL Backticks, les identifiants PostgreSQL à double guillemet et et :: Casts et SQL Server Square Brackets plutôt que de les réécrire. La norme ANSI SQL définit le noyau partagé, mais aucune base de données de production ne parle de SQL standard pur, donc la tolérance de dialecte est une exigence pour qu'un formateur soit utile sur les requêtes réelles.
Est-il sûr de coller des requêtes de production dans un formateur SQL en ligne ?
Uniquement dans un côté client, car SQL est inhabituellement sensible : les requêtes exposent votre schéma et les requêtes copiées à partir des journaux contiennent souvent des valeurs littérales telles que des e-mails ou des ID dans WHERE clauses. le Formateur SQL Toolz.dev Traitez tout dans votre navigateur sans rien transmis ou stocké. Vérifiez vous-même en regardant l'onglet Réseau pendant que vous collez. Évitez les formateurs basés sur des serveurs pour tout ce qui provient de la production.
Le formatage conserve-t-il les commentaires SQL ?
Oui - les deux -- Commentaires en ligne et /* */ Les commentaires de blocage sont intacts, contrairement à la minification, qui les supprime. Cela rend la mise en forme sécurisée des requêtes annotées et des procédures stockées où les commentaires sont soumis à une intention. Utilisez-le : un commentaire d'une ligne expliquant un LEFT JOIN Ou une condition inhabituelle est la protection la moins chère contre le prochain développeur "fixation" quelque chose qui n'était pas cassé.
