SQL is sinds 1987 gestandaardiseerd en wordt onderhouden als ISO/IEC 9075, hoewel elke engine zijn eigen dialect erbovenop toevoegt - en dat is precies de reden waarom een formatter moet parseren in plaats van patroonmatch.
De slechtste vraag die ik ooit heb moeten beoordelen, waren 340 regels op een enkele logische gedachte: een inkomstenrapport voor een Laravel SaaS, geschreven als één DB::select() Raw String, in acht maanden opgebouwd door drie ontwikkelaars die elk een ander idee hadden over hoofdletters en geen enkele over regeleinden. Ergens in die muur van tekst, a LEFT JOIN was stilletjes een geworden INNER JOIN tijdens een refactor verdwenen klanten met nul bestellingen uit het rapport. De bug was één woord. Het vinden ervan duurde anderhalve dag - niet omdat de logica moeilijk was, maar omdat de zoekopdracht moeilijk was onleesbaar, en onleesbare code verbergt zijn bugs in het zicht.
Hier is het ding over SQL: de database geeft niet om uw opmaak. de parser leest select id,name from users where active=1 en SELECT id, name FROM users WHERE active = 1 als dezelfde verklaring, produceert hetzelfde uitvoeringsplan, retourneert dezelfde rijen in dezelfde tijd Het formatteren van SQL is puur voor mensen - dat is precies waarom het & #39; de moeite waard is om te doen, omdat mensen degenen zijn die het beoordelen, debuggen om 02.00 uur en erven het drie taken later Een query die u kunt & # 39; t skim is een query die u kunt & # 39; t verifiëren.
een SQL-formatter zet elke query - geplakt uit een log, een ORM' s debug-uitvoer, een coworker' s Slack-bericht, een legacy opgeslagen procedure - in consistent ingesprongen, consistent in een behuizing opgenomen, controleerbare SQL in één klik Die op Toolz.dev draait volledig in uw browser, wat meer belangrijk is voor SQL dan voor bijna elke andere tekst die u ' d plakt in een online tool, omdat productiequery's uw schema en soms uw gegevens bevatten.
Deze gids behandelt hoe het te gebruiken, de opmaakconventies die er echt toe doen (trefwoordbehuizing, inspringing en de eeuwige kommaoorlog), en de workflows waar een formatter zichzelf dagelijks betaalt.
tl;dr: Plak een vraag in de Toolz.dev SQL-formatter en krijg consequent ingesprongen, trefwoord-gecasede SQL terug - direct, gratis, client-side, geen aanmelding Formatteren verandert nooit wat een query doet of hoe snel deze loopt; het verandert of een mens het kan verifiëren Conventies die de moeite waard zijn om te nemen: hoofdletters trefwoorden, één clausule per regel, inspringen onder elke clausule, een kommastijl kiezen en stoppen met discussiëren over het Koppel het met de JSON-formatter voor de API-laag boven uw database en de Tekstdiff-tool Voor het vergelijken van twee versies van een query.
Belangrijkste kenmerken
Consistente inspringing met één klik
De opmaakmachine's kernzet: elke hoofdzin - SELECT, FROM, WHERE, GROUP BY, ORDER BY - begint zijn eigen regel, met kolommen, voorwaarden, en voegt zich ingesprongen onder Dit is de " river" structuur ervaren SQL lezers scannen door: het oog loopt langs de linker rand lezen clausule trefwoorden, dan duikt in welke clausule er toe doet Een 60-regelige geformatteerde query met duidelijke structuur beoordelingen sneller dan een 6-regelige ongeformatteerde, want de structuur doet de helft van de lezing voor jou Mijn 340-regelige horrorverhaal zou een twintig minuten durende recensie zijn geweest met deze vorm - het veranderde joint-type zou alleen op zijn eigen lijn hebben gezeten, zichtbaar verkeerd.
normalisatie van het trefwoordca
SELECT tegen select echt niet' maakt voor elke database uit - SQL-trefwoorden zijn hoofdletterongevoelig volgens de standaard, en elk dialect eert dat. Het is echter enorm belangrijk voor een codebase, omdat gemengde behuizing visuele ruis is waardoor structureel identieke zoekopdrachten er anders uitzien. Hoofdletterstrefwoorden zijn de oudere conventie, daterend uit editors zonder syntaxisaccentuering, waar SELECT in caps was de markering. Ik schrijf nog steeds hoofdletters - trefwoorden springen tegen kleine letters, en het overleeft elke context die de markering verwijdert: logboeken, diffs, e-mail in platte tekst, terminaluitvoer. De formatter normaliseert naar de door u gekozen conventie, dus een codebasis geschreven door vijf mensen leest alsof deze door één persoon is geschreven.
Verwerkt ORM en log output
De vragen die het meest nodig zijn om op te maken zijn degene die geen mens schreef: welsprekende en activerecord-output, doctrine's gegenereerde joins, de single-line monsters in je logboek met langzame query. ORM-uitvoer arriveert als één regel met door de machine gegenereerde aliassen (t0, t1, laravel_reserved_0), en als je het rauw leest, krijg je hoofdpijn. Mijn meest voorkomende gebruik van de formatter: pak de query van Laravel' s querylog of telescoop, formatteer deze en kijk daadwerkelijk wat de ORM besloot te doen - wat de eerste stap is van elke & quot; waarom is dit eindpunt slow" onderzoek, vlak daarvoor EXPLAIN.
Tolerantie voor meerdere dialecten
Real-World SQL is een familie van dialecten: MySQL's BackTick-geciteerde identifiers, PostgreSQL's dubbele aanhalingstekens en :: Casts, SQL Server's vierkante haken en TOP, SQLite's gemakkelijke alles. Een nuttige formatter behandelt ze allemaal zonder dat je eerst een dialect verklaart, waarbij je dialectspecifieke syntaxis behoudt in plaats van "corrigeren" het. De ANSI/ISO SQL-standaard (ISO/IEC 9075) definieert de Common Core, maar niemand schrijft in de praktijk pure standaard SQL, en een formatter die alleen de standaard uitspreekt, zou op de eerste backtick stikken.
Bewaart semantiek, gegarandeerd
Het vermelden waard expliciet omdat het ' is de angst die mensen tegenhoudt: opmaak kan de resultaten niet veranderen. Witruimte en trefwoordcases zijn niet semantisch in SQL - het enige historische voorbehoud is dat Snijl letterlijke worden wel of niet hoofdlettergevoelig vergeleken, en een formatter raakt nooit de binnenkant van uw geciteerde tekenreeksen. De uitvoer is dezelfde instructie, byte-for-byte waar bytes belangrijk zijn. EXPLAIN Op beide versies als je het wilt zien: identieke plannen.
Client-side, wat hier echt telt
SQL is de meest gevoelige tekstcategorie die routinematig in online tools wordt geplakt. Query's onthullen uw schema - tabelnamen, kolomnamen, relaties - en query's die uit logboeken zijn gekopieerd, bevatten vaak letterlijke waarden: e-mails erin WHERE Clausules, ID-bereiken, af en toe iets dat nooit in een queryreeks had mogen zitten. de Toolz.dev-formatter verwerkt alles in uw browser; er wordt niets verzonden Specifiek voor SQL, I'd bellen client-side processing een vereiste, niet een functie - verifieer het in het tabblad Netwerk en ontspan vervolgens.
Hoe de SQL-formatter te gebruiken
Stap 1: Leg de query vast
Kopieer de SQL van de bron: uw migratiebestand, een opgeslagen procedure, de ORM's debug-uitvoer (DB::listen() of telescoop in Laravel, ActiveRecord::Base.logger in rails), het logboek met langzame query of het tabblad Query van uw APM-tool. Als het uit een logboek kwam, is het mogelijk aan aanhalingstekens of parameterplaatsaanduidingen ontsnapt (?, $1) - dat's prima, formatters behandelen tijdelijke aanduidingen, en het duidelijk zien ervan is vaak het punt.
Stap 2: Plakken en formatteren
Open de SQL-formatter, plakken, en de opgemaakte versie verschijnt Geen dialectceremonie, geen configuratie nodig om een goede standaard te krijgen Als uw query meerdere instructies bevat, gescheiden door puntkomma's, formatteren ze als afzonderlijke instructies - handig voor het lezen van migratiescripts in hun geheel.
Stap 3: Lees het als een recensent
Doe nu waar het opmaak bestaat voor: scan de linkerrand. Welke tabellen zijn samengevoegd en met welke join-types? doet de WHERE clausule hebben de voorwaarden die u verwacht - en zijn de AND/OR groeperingen haakjes zoals u achten ze groeperen? (Operatorvoorrang in SQL Puts AND vooruit OR, en niet-gepleide mixen van de twee zijn de op een na grootste bugbron die ik in de recensie zie, direct na verkeerde join-typen.) Geformatteerde SQL maakt beide fouten in seconden zichtbaar.
Stap 4: Kopieer het terug - selectief
Voor vragen die naar uw codebase gaan, kopieert u de geformatteerde versie naar de migratie, de ->select() rauwe uitdrukking, de .sql bestand. Voor eenmalige foutopsporing: doe geen moeite om round-tripping; de geformatteerde kopie diende zijn doel op het moment dat u het las. Een plek nee Om geformatteerde SQL te plakken: terug in systemen die query's opslaan als configuratiestrings, waarbij iemands diff-tooling nu een muur met veranderingen in de witruimte laat zien. Formaat om altijd te lezen; opnieuw formatteert opgeslagen zoekopdrachten alleen wanneer u voorbereid bent om het diff te bezitten.
Stap 5: Standaardiseer de teamconventie
De opmaakmachine' De grootste waarde is compounding: kies de conventies die u kunt automatiseren - trefwoord hoofdletter en inspringbreedte zijn de twee die deze opmaakmachine rechtstreeks bestuurt - formatteer alles wat nieuw is op weg naar de codebasis, en de wrijving bij SQL-recensies neemt permanent af Schrijf de keuze op in uw bijdragende gids. De specifieke gekozen conventie is veel minder belangrijk dan iedereen die dezelfde conventie gebruikt - een zin die geldt voor elk opmaakdebat in software en die door ongeveer niemand halverwege het debat wordt geloofd.
Technische diepe duik: de conventies die het waard zijn om meningen over te hebben
trefwoord behuizing. Hoofdlettersleutelwoorden, kleine letters-ID's zijn de dominante conventie en mijn aanbeveling Het argument is & #39; t traditie - it & #39; robuustheid Syntaxisaccentuering verdwijnt in logboeken, terminals, reacties op codebeoordeling en Stack Overflow-antwoorden die in Slack zijn geplakt; Hoofdlettersleutelwoorden markeren die met de tekst reizen Het tegenargument (alles in kleine letters laten markeren door de editor) is coherent en I & #39; hebben gewerkt in codebases die het met plezier gebruikten Wat& #39; niet coherent is mixen, wat je krijgt zonder een opmaakmaker die de keuze afdwingt.
Eén clausule per regel, ingesprongen inhoud. De structurele regel met de hoogste uitbetaling. SELECT Start een lijn; de kolommen zijn hieronder ingesprongen (of op dezelfde lijn als kort). iedereen JOIN krijgt een eigen lijn met zijn ON toestand zichtbaar - voeg voorwaarden verborgen midden-lijn zijn waar fout-voeg bugs verbergen. WHERE Voorwaarden Stapel één per regel, uitgelijnd, met AND/OR Elke lijn leidt zodat de logische structuur verticaal leest. Wanneer de voorwaarden van een query als een kolom worden gelezen, is een ontbrekende voorwaarde zichtbaar als een gat in een patroon, die menselijke ogen uitzonderlijk goed zijn in het spotten.
De kommaoorlog. Sleep komma's (na elke kolom) lees op natuurlijke wijze; leidende komma's (voor elke kolom, bij het begin van de regel) maak de interpunctie structureel:
-- Trailing (most common)
SELECT
u.id,
u.email,
o.total
-- Leading (the DBA classic)
SELECT
u.id
, u.email
, o.total
Voorstanders van de leidende komma hebben twee echt goede punten: door elke regel uit te spreken, behalve de eerste, wordt de instructie nooit verbroken, en een ontbrekende komma is onmiddellijk zichtbaar aan de linkermarge. Voorstanders van de sleepkomma hebben er een: het lijkt erop dat elke andere taal die je schrijft Ik schrijf achterliggende komma's en voel me er niet langer slecht over - maar merk op dat SQL dat, in tegenstelling tot het moderne JavaScript of Python, wel doet nee vergeef een bungelende komma na de laatste kolom, daarom bestaat dit debat überhaupt en waarom de leidende stijl weigert te sterven in DBA-kringen Volledige openbaarmaking: de Toolz.dev-formatter neemt de mainstream kant en zendt achterliggende komma's uit - het heeft geen leidende kommamodus, dus als je ' een toegewijde leading-comma shop bent, is dit de enige conventie die het won ' t herformatt voor jou Kies een huisstijl, pas deze consistent toe en ga verder.
Wat opmaak niet doet. Het optimaliseert niet. een geformatteerde SELECT * Over een join van vijf tafels is een prachtig ingesprongen prestatieprobleem. Opmaak is de eerste vereiste voor optimalisatie - je kunt niet redeneren over een vraag die je niet kunt lezen - maar de redenering vereist nog steeds EXPLAIN, indexbewustzijn en het kennen van uw gegevensvorm. Ik beschouw de pijplijn als: format, lees, EXPLAIN, dan optimaliseren. Stap één overslaan maakt je niet sneller; het maakt stappen twee tot vier langzamer. Dezelfde discipline past één laag toe bij de API, daarom is de JSON-formattergids maakt een structureel identiek argument over payloads.
Opmerkingen overleven. In tegenstelling tot minificatie behoudt opmaak opmerkingen - -- Reacties op de lijnen en /* */ Blokken komen intact door. Gebruik ze. a -- deliberately LEFT JOIN: include customers with no orders Commentaar hierboven Een join is de goedkoopste bugverzekering die ooit is geschreven, en het is de opmerking die mijn 340-regelige horrorverhaal nodig had.
Veelvoorkomende gebruiksgevallen
Code Beoordeling
Ongeformatteerde SQL in een pull-verzoek is een beoordeling die is't gaat gebeuren - de recensent' zijn ogen glijden van de muur van tekst en de goedkeuring landt toch Het formatteren van de query voordat de PR wordt geopend is basis beleefdheid met meetbare uitbetaling: join types, condition groupings, en column lists worden individueel zichtbaar, wat betekent dat ze individueel reviewbaar worden Elke echte SQL bug I & #39; zijn gevangen in beoordeling - de verkeerde join, de unparethesized OR, de DELETE de helft missen WHERE clausule - Ik heb gepakt omdat de query goed genoeg was opgemaakt om regel voor regel te lezen.
ORM-gegenereerde zoekopdrachten debuggen
ORM's zijn geweldig tot het eindpunt langzaam is, op welk punt je de daadwerkelijke SQL - en ORM-uitvoer altijd één dichte lijn moet zien Formatteer het en het verhaal verschijnt: de N+1 die gretig laden miste, de join the relationship-definitie stilletjes toegevoegd, de ORDER BY op een niet-geïndexeerde kolom. In Laravel-werk is dit een ritueel van meerdere keren per week: telescoop, kopie, formaat, huiver, repareer de welsprekende code, herhaal. De formatter diagnosticeert zelf niets; het maakt de query zo goed leesbaar dat gijlieden kan.
Archeologie op oude vragen
Elk systeem met een lange levensduur heeft ze: de opgeslagen procedure uit 2015, de rapportageweergave die niemand durft aan te raken, de query ingebed in een configuratiebestand met de oorspronkelijke auteur' s-opmaak (dat wil zeggen geen). Voordat u de oudere SQL wijzigt, formatteert u deze en leest u deze van begin tot eind - u ' zal routinematig omstandigheden vinden die kunnen ' Het is nooit waar, voegt zich bij tabellen die geen schrijfbewerkingen meer ontvangen, en logica de aannames van het huidige team ' Het formatteren van eerste beurten & quot; encary legacy query" into; lang maar leesbaar queryprobleem; dat is een ander en beter probleem.
Queryversies vergelijken
Wanneer een rapport' s nummers tussen releases veranderen, is de vraag & quot; wat er in de query is veranderd, & quot; en het antwoord vereist het verspreiden van twee versies - wat alleen werkt als beide eerst identiek zijn geformatteerd. Formatteer beide met dezelfde instellingen en voer ze vervolgens door de Tekstdiff-tool: Het geluid verdwijnt en de twee veranderde lijnen staan op zichzelf. Deze exacte reeks vond uiteindelijk mijn innerlijke-join-bug. ik doe het nu vooruit de anderhalve dag van verwarring in plaats van erna.
Onderwijs en documentatie
SQL in tutorials, runbooks en interne documenten wordt veel vaker gelezen dan geschreven, door lezers die minder bekend zijn met het schema dan de auteur. Geformatteerde voorbeelden met trefwoorden in hoofdletters en een structuur van één concept per regel zijn dramatisch gemakkelijker om van te leren - de structuur leert naast de inhoud. Als ik documentatie schrijf met ingebedde zoekopdrachten, doorloopt iedereen eerst de opmaak; ongeformatteerde SQL in documenten vertelt de lezer dat de auteur dat heeft gedaan ' Ik verwacht niet dat iemand het daadwerkelijk leest.
Opmaakconventies vergeleken
| Conventie keuze | Optie A | optie B | mijn nemen |
|---|---|---|---|
| trefwoord case | SELECT (Upcase) |
select (kleine letters) |
Hoofdletters - overleeft contexten zonder te benadrukken |
| Identifier-geval | slang_case | Overeenkomen met tabeldefinities | Match definities; vecht nooit tegen het schema |
| komiek | achterblijvend (id,) |
leidend (, id) |
Achteraan, maar leiden is verdedigbaar - kies er maar één |
| Clausule Lay | Eén clausule per regel | Compacte enkele lijn | Eén per regel voor alles wat triviaal is |
AND/OR plaatsing |
Leiding van elke conditieregel | Sleeping vorige regel | Toonaangevend - logica leest verticaal |
| Sluit je aan bij voorwaarden | ON op zijn eigen lijn of inline met JOIN |
begraven middenlijn | zichtbaar met de join, altijd |
| Inspringing breedte | 2 spaties | 4 spaties | ofwel; SQL nestelt minder dan JSON, dus 4 is hier prima |
Geen van deze rijen heeft een verkeerd antwoord, en dat & #39; s precies de val - omdat elke optie verdedigbaar is, procederen teams ze voor altijd opnieuw, tenzij een formatter de beslissing mechanisch maakt De winnende zet is saai: alles kiezen, configureren, formatteren en de teruggewonnen argumenttijd besteden aan dingen die van invloed zijn op het uitvoeringsplan. Voor de rest van de dagelijkse toolkit hieromheen, zie de Handleiding voor coderingshulpmiddelen en de bredere Webontwikkelaar Toolkit.
FAQ
Wat doet een SQL-formatter?
Een SQL-formatter herschrijft een query' s witruimte, regeleinden en sleutelwoordbehuizing in een consistente, leesbare structuur - elke clausule op zijn eigen regel, voorwaarden en ingesprongen kolommen, trefwoorden genormaliseerd naar één naamval De betekenis van statement' is onaangeroerd: SQL-parsers negeren de opmaak volledig, dus de geformatteerde query retourneert identieke resultaten met een identiek uitvoeringsplan. De wijziging is puur bedoeld voor de mensen die de query beoordelen, debuggen en onderhouden.
Verandert het formatteren van SQL de prestaties van de query?
Nr. Whitespace en trefwoordcase zijn niet semantisch in SQL - de database parseert beide versies in dezelfde interne representatie en produceert hetzelfde uitvoeringsplan, dat u kunt verifiëren door uit te voeren EXPLAIN op elk. Formatteren is de voorwaarde voor prestatiewerk in plaats van prestatiewerk zelf: u kunt niet redeneren over indexen en orders aansluiten in een query die u niet kunt lezen.
Moeten SQL-zoekwoorden hoofdletters of kleine letters zijn?
Beide zijn geldig - SQL-trefwoorden zijn hoofdletterongevoelig volgens de standaard - dus dit is een leesbaarheidsconventie, geen correctheidsregel. Hoofdletterstrefwoorden (SELECT, FROM, WHERE) blijven de meest voorkomende keuze omdat ze fungeren als ingebouwde markering in contexten die kleuren: logboeken, diffs, terminals en berichten in een platte tekst. Wat je ook kiest, consistentie in de codebase is veel belangrijker dan de keuze zelf.
Wat zijn de belangrijkste komma's in SQL en waarom gebruiken mensen ze?
Leading-comma-stijl plaatst de komma aan het begin van elke kolomlijn (, email) in plaats van het einde van de vorige Voorstanders vinden het leuk omdat commentaar geven op een kolom behalve de eerste nooit een syntaxisfout oplevert, en ontbrekende komma's direct zichtbaar zijn aan de linkermarge - echte voordelen, aangezien SQL dat wel doet en#39; tolereer geen bungelende komma na de laatste kolom zoals het moderne JavaScript dat doet Achterliggende komma's blijven gebruikelijker; ofwel werkt het als het consistent wordt toegepast.
Kan ik SQL formatteren die is gegenereerd door een ORM zoals Eloquent of ActiveRecord?
Ja, en het & #39; is een van de beste toepassingen van een formatter - ORM debug-uitvoer arriveert als een enkele dichte lijn met machine-gegenereerde aliassen, en het formatteren ervan is de eerste stap van het diagnosticeren van langzame eindpunten en N+1-problemen Leg de query vast van uw ORM's logboekregistratie (Laravel Telescope, ActiveRecord-logboeken), plak deze in de SQL-formatter, en lees wat de ORM eigenlijk heeft gebouwd voordat hij naar EXPLAIN.
Werkt de formatter met MySQL, PostgreSQL en SQL Server-syntaxis?
Ja - praktische opmaakapparaten verwerken de belangrijkste dialecten' eigenaardigheden, met behoud van MySQL-backticks, PostgreSQL dubbel geciteerde identificatiegegevens en :: Casts en SQL Server Square Haakjes in plaats van ze te herschrijven. De ANSI SQL-standaard definieert de gedeelde kern, maar geen enkele productiedatabase spreekt pure standaard SQL, dus dialecttolerantie is een vereiste voor een formatter om nuttig te zijn voor echte zoekopdrachten.
Is het veilig om productievragen in een online SQL-formatter te plakken?
Alleen in een client-side, omdat SQL ongewoon gevoelig is: query's tonen uw schema en query's die uit logboeken worden gekopieerd, bevatten vaak letterlijke waarden zoals e-mails of ID's in WHERE clausules. de Toolz.dev SQL-formatter verwerkt alles in uw browser zonder dat er iets is verzonden of opgeslagen - verifieer het zelf door het tabblad Netwerk te bekijken terwijl u plakt Vermijd servergebaseerde formatters voor alles wat van de productie komt.
Behoudt het formatteren SQL-opmerkingen?
Ja - beide -- Reacties op de lijnen en /* */ Blokkeer opmerkingen gaan intact, in tegenstelling tot minification, waardoor ze worden verwijderd. Dit maakt het formatteren veilig voor geannoteerde zoekopdrachten en opgeslagen procedures waar opmerkingen de intentie hebben. Gebruik dat: een eenregelige opmerking die een opzettelijke uitleg geeft over een LEFT JOIN Of een ongebruikelijke voorwaarde is de goedkoopste bescherming tegen de volgende ontwikkelaar "fixing" iets dat niet kapot was.
