SQL est standardisé depuis 1987 et est maintenu comme ISO/CEI 9075« , bien que chaque moteur ajoute son propre dialecte en haut - c'est exactement pourquoi un formateur doit analyser plutôt que de faire correspondre des modèles ».
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'un refactor, et les clients avec zéro ordre ont disparu du rapport Le bug était un mot Trouver cela a pris un jour et demi - non pas parce que la logique était dure, 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 en même temps Formater SQL est purement pour les humains - ce qui est exactement pourquoi il' ; vaut la peine d'être fait, parce que les humains sont ceux qui l'examinent, le déboguent à 2 heures du matin, et héritent de lui trois tâches plus tard Une requête que vous pouvez' ; t skim est une requête que vous pouvez' ; t vérifier.
un Formateur SQL transforme n'importe quelle requête - collée à partir d'un journal, d'une sortie de débogage ORM' ; s, un coworker' ; s Slack message, une procédure stockée héritée - en SQL constamment en retrait, systématiquement mis en casse et révisable en un clic Celui sur Toolz.dev s'exécute entièrement dans votre navigateur, ce qui compte plus pour SQL que pour presque tout autre texte que vous' ; d coller dans un outil en ligne, car les requêtes de production portent 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 constamment en retrait, SQL avec le sous-mot-clé - instantané, gratuit, côté client, pas d'inscription Le formatage ne change jamais ce que fait une requête ni la vitesse à laquelle elle s'exécute ; il change si un humain peut la vérifier Conventions qui valent la peine d'être adoptées : mots-clés majuscules, une clause par ligne, un tiret sous chaque clause, et choisissez un style de virgule et arrêtez de vous en disputer Associez-le au 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 formateur' ;s mouvement principal : 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 en dessous. Il s'agit du " ; river" ; les lecteurs SQL expérimentés en structure passent en revue : l'œil descend sur les mots-clés de la clause de lecture du bord gauche, puis plonge dans la clause la plus importante. Une requête formatée de 60 lignes avec des critiques claires de la structure plus vite qu'une non formatée de 6 lignes, parce que la structure fait la moitié de la lecture pour vous Mon histoire d'horreur de 340 lignes aurait été une revue de vingt minutes avec cette forme - le type de jointure modifié aurait été assis seul sur sa propre ligne, visiblement faux.
Normalisation de cas de mots clés
SELECT contre select ne fait vraiment pas & #39 ; peu importe à n'importe quelle base de données - les mots-clés SQL sont insensibles à la casse selon la norme, et chaque dialecte honore cela Cela compte énormément pour une base de code, cependant, parce que le casse mixte est un bruit visuel qui rend les requêtes structurellement identiques différentes Les mots-clés majuscules sont la convention plus ancienne, datant des éditeurs sans coloration syntaxique, où SELECT en majuscules Était la mise en évidence. J'écris toujours en majuscules - les mots-clés apparaissent contre les identifiants minuscules, et ils survivent à tous les contextes qui mettent en évidence : les journaux, les différences, les e-mails en texte brut, la sortie du terminal. Le formateur se normalise à la convention de votre choix, donc une base de code écrite par cinq personnes se lit comme si elle avait été écrite par un.
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 ressentez des maux de tête. Mon utilisation la plus fréquente du formateur : saisissez la requête de Laravel' ; le journal des requêtes ou le télescope, formatez-le et voyez réellement ce que l'ORM a décidé de faire - qui est la première étape de chaque " ; pourquoi ce point final est-il lent et total ; 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 déclaré explicitement parce que c'est la peur qui arrête les gens : le formatage ne peut pas changer les résultats. L'espace et le cas des mots clés ne sont pas sémantiques dans SQL - la seule mise en garde historique étant celle-là 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 colonnes, relations - et les requêtes copiées à partir des journaux contiennent fréquemment des valeurs littérales : les e-mails en 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 traite tout dans votre navigateur ; rien n'est transmis Pour SQL en particulier, I' ; d appeler le traitement côté client 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) - ça' ; Très bien, les formateurs gèrent les espaces réservés, et les voir clairement est souvent le sujet.
Étape 2 : Coller et formater
Ouvrez le Formateur SQL(en anglais), collez, et la version formatée apparaît Aucune cérémonie dialectale, aucune configuration requise pour obtenir un bon défaut Si votre requête inclut plusieurs instructions séparées par des points-virgules, elles se formaturent sous forme d'instructions séparées - utiles pour lire les scripts de migration entiers.
É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 clause ont les conditions que vous attendez - et sont les 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 : Recopiez-le - 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
Le formateur' ; La plus grande valeur est la composition : choisissez les conventions que vous pouvez automatiser - la casse des mots clés et la largeur d'indentation sont les deux que ce formateur contrôle directement - formatez tout ce qui est nouveau sur le chemin de la base de code, et la friction de révision SQL diminue de façon permanente. Écrivez le choix dans votre guide de contribution. La convention spécifique choisie compte beaucoup moins que tout le monde utilisant le même - une phrase qui est vraie pour chaque débat sur le formatage dans les logiciels et que personne ne croit à peu près à mi-débat.
Plongée approfondie technique : les conventions qui valent la peine d'avoir des avis sur
Coffret de mots clés. Mots-clés en majuscules, identifiants en minuscules est la convention dominante et ma recommandation L'argument est & #39 ; t tradition - it & #39 ; s robustesse La surbrillance syntaxique disparaît dans les journaux, les terminaux, les commentaires de révision de code et les réponses Stack Overflow collées dans Slack ; les mots-clés en majuscules mettent en évidence que les déplacements avec le texte Le contre-argument (tout en minuscules, laissez l'éditeur mettre en évidence) est cohérent et I & #39 ; a travaillé dans des bases de code qui l'utilisaient avec bonheur Ce que & #39 ; n'est pas cohérent est le mixage, c'est ce que c'est le mixage, c'est ce que vous obtenez sans formateur qui impose 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 jointure cachées au milieu de la ligne sont l'endroit où se cachent les bugs de mauvaise jointure. 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 défenseurs des virgules principales ont deux points véritablement bons : commenter n'importe quelle ligne, sauf la première, ne brise jamais l'énoncé, et une virgule manquante est instantanément visible sur la marge gauche. Les défenseurs des virgules traînantes en ont un : il ressemble à tous les autres langages que vous écrivez. J'écris des virgules traînantes et j'ai cessé de me sentir mal à ce sujet - mais notez que SQL, contrairement au JavaScript ou au Python modernes, en fait non pardonnez une virgule pendante après la dernière colonne, 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é grand public et émet des virgules traînantes - il n'a pas de mode de virgule principale, donc si vous et n°39 ; êtes un magasin de virgule principale engagé, c'est la seule convention qu'il a gagnée et n°39 ; pas de reformatage pour vous. Choisissez un style 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 l'optimisation - vous ne pouvez pas raisonner sur une requête que vous ne pouvez pas lire - mais le raisonnement exige 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 requête pull est une évaluation qui est & #39 ; cela va se produire - le réviseur & #39 ; ses yeux glissent du mur de texte et l'approbation atterrit quand même Le formatage de la requête avant d'ouvrir le PR est une courtoisie de base avec un gain mesurable : les types de jointure, les groupements de conditions et les listes de colonnes deviennent visibles individuellement, ce qui signifie qu'ils deviennent révisables individuellement. Chaque véritable bug SQL I' ; a été pris en compte - 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 bien formatée pour être lue ligne par ligne.
Déboguer les requêtes générées par ORM
Les ORM sont merveilleux jusqu'à ce que le point final 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 que le chargement enthousiaste a manqué, la définition de la relation est ajoutée silencieusement, le 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 à longue durée de vie en possède : la procédure stockée de 2015, la vue de rapport que personne n'ose toucher, la requête intégrée dans un fichier de configuration avec le formatage original author' ; s (c'est-à-dire, aucun).Avant de modifier le SQL existant, formatez-le et lisez-le bout à bout - vous' ; trouvera régulièrement des conditions qui peuvent' ; ne sont jamais vraies, rejoint des tables qui ne reçoivent plus d'écritures, et logique l'équipe actuelle' ; les hypothèses contredisent Format des premiers tours " ; requête et quot hérités effrayantes ; dans une requête longue mais lisible ; qui est un problème différent et.
Comparaison des versions de requête
Lorsqu'un rapport & #39 ; s les numéros changent entre les versions, la question est " ; ce qui a changé dans la requête, " ; et la réponse nécessite de diffamer deux versions - ce qui ne fonctionne que si les deux sont formatées de manière identique en premier. 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 tutoriels, 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 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 passe d'abord par le formateur ; SQL non formaté dans les documents indique au lecteur que l'auteur l'a fait et n°39 ; Je ne m'attends à ce que quiconque 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) |
En majuscules - 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) |
Traîner, mais mener 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 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 que' ; est précisément le piège - parce que chaque option est défendable, les équipes les re-litigent pour toujours à moins qu'un formateur ne rende la décision mécanique Le coup gagnant est ennuyeux : choisissez, configurez, formatez tout, et passez le temps d'argumentation récupéré sur des choses qui affectent le plan d'exécution Pour le reste de la boîte à outils quotidienne autour de celle-ci, voir 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 un espacement, des sauts de ligne et un casse de mot-clé de query' ; s dans une structure cohérente et lisible - chaque clause de sa propre ligne, conditions et colonnes en retrait, mots-clés normalisés à un cas La signification de statement' ; s est intacte : 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 concerne uniquement les humains qui examinent, déboguent et maintiennent la requête.
Le formatage de SQL modifie-t-il les performances de la requête ?
Non. Les espaces et les mots-clés ne sont pas sémantiques dans 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 majuscules (Uppercase keywords)SELECT, 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 de la précédente Les avocats aiment parce que commenter n'importe quelle colonne sauf la première ne produit jamais d'erreur de syntaxe, et les virgules manquantes sont instantanément visibles à la marge gauche - des avantages réels, puisque SQL does' ; t tolèrent une virgule pendante après la colonne finale comme le fait le JavaScript moderne Les virgules traînantes restent plus courantes ; soit fonctionne si appliqué de manière cohérente.
Puis-je formater SQL généré par un ORM comme Eloquent ou ActiveRecord ?
Oui, et c'est & #39 ; est l'une des meilleures utilisations d'un formateur - la sortie de débogage ORM arrive comme une seule ligne dense avec des alias générés par machine, et le formater est la première étape du diagnostic des points de terminaison lents et des problèmes N+1. Capturez la requête de votre journalisation ORM& #39 ; s (Laravel Telescope, journaux ActiveRecord), 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' ; bizarreries, préservation des backticks MySQL, identifiants PostgreSQL double-cité 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 traite tout dans votre navigateur sans rien de transmis ou stocké - vérifiez-le vous-même en regardant l'onglet Réseau pendant que vous collez Évitez les formateurs basés sur le serveur pour tout ce qui vient 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é.
