SQL è standardizzato dal 1987 ed è mantenuto come ISO/IEC 9075, anche se ogni motore aggiunge il proprio dialetto in cima, motivo per cui un formattatore deve analizzare anziché abbinare il modello.
La peggiore domanda che abbia mai dovuto rivedere è stata 340 righe su un unico pensiero logico: un rapporto sulle entrate per un saaravel saas, scritto come uno DB::select() String RAW, costruito in otto mesi da tre sviluppatori che avevano ciascuno un'idea diversa sulla capitalizzazione e nessuna delle interruzioni di riga. da qualche parte in quel muro di testo, a LEFT JOIN era diventato tranquillamente un INNER JOIN durante un refactor, e i clienti con zero ordini svanirono dal report Il bug era di una parola Trovare ci volle un giorno e mezzo - non perché la logica fosse dura, ma perché la query lo era illeggibile, e il codice illeggibile nasconde i suoi bug in bella vista.
Ecco la cosa su SQL: al database non importa della tua formattazione. il parser legge select id,name from users where active=1 e SELECT id, name FROM users WHERE active = 1 come stessa istruzione, produce lo stesso piano di esecuzione, restituisce le stesse righe nello stesso tempo Formattazione SQL è puramente per gli esseri umani - che è esattamente il motivo per cui it's vale la pena fare, perché gli esseri umani sono quelli che lo rivedono, debug alle 2 AM, ed ereditare tre lavori dopo Una query si può' t skim è una query si può' t verificare.
un' Formattatore SQL trasforma qualsiasi query - incollata da un registro, un output di debug ORM's, un messaggio Slack di coworker's, una procedura memorizzata legacy - in SQL costantemente rientrato, costantemente in maiuscolo e revisionabile in un clic Quello su Toolz.dev viene eseguito interamente nel browser, il che conta più per SQL che per quasi tutti gli altri testi che tu'd incolla in uno strumento online, perché le query di produzione trasportano il tuo schema e talvolta i tuoi dati.
Questa guida illustra come usarlo, le convenzioni di formattazione che contano effettivamente (cassa di parole chiave, rientro e guerra delle virgole eterne) e i flussi di lavoro in cui un formattatore si paga da solo ogni giorno.
tl; dr: Incolla qualsiasi query in Formattatore SQL di Toolz.dev e torna indietro SQL costantemente rientrato e basato su parole chiave - istantaneo, gratuito, lato client, senza iscrizione La formattazione non cambia mai ciò che fa una query o la velocità con cui viene eseguita; cambia se un essere umano può verificarla Convenzioni che vale la pena adottare: parole chiave maiuscole, una clausola per riga, rientro sotto ogni clausola, e scegli uno stile di virgola e smetti di discuterne Abbinalo al Formattatore JSON per il livello API sopra il tuo database e il Strumento Diff di testo Per confrontare due versioni di una query.
Caratteristiche principali
Rientro coerente con un clic
Il formattatore's mossa principale: ogni clausola principale - SELECT, FROM, WHERE, GROUP BY, ORDER BY - inizia la propria riga, con colonne, condizioni e join rientrati sotto Questo è il & quot;river" struttura con esperienza SQL lettori scansion by: l'occhio corre lungo il bordo sinistro leggendo le parole chiave della clausola, quindi si tuffa in qualunque clausola importa Una query formattata di 60 righe con chiare revisioni della struttura più a lungo di una 6 righe non formattata, perché la struttura sta facendo metà della lettura per te La mia storia horror di 340 righe sarebbe stata una recensione di venti minuti con questa forma - il tipo di join modificato sarebbe rimasto seduto da solo sulla propria linea, visibilmente sbagliato.
Normalizzazione del caso di parole chiave
SELECT contro select genuinamente non importa & #39; t importa a qualsiasi database - le parole chiave SQL sono case-insensitive secondo lo standard, e ogni dialetto onora che Importa enormemente a una base di codice, però, perché il case misto è rumore visivo che rende le query strutturalmente identiche aspetto diverso Parole chiave maiuscole sono la convenzione più vecchia, datazione da editor senza evidenziazione di sintassi, dove SELECT in maiuscolo era l'evidenziazione Scrivo ancora maiuscolo - le parole chiave si scontrano con gli identificatori minuscoli, e sopravvive a ogni contesto che spoglia evidenziando: registri, diff, email in testo normale, output del terminale Il formattatore si normalizza alla convenzione scelta in modo che una base di codice scritta da cinque persone si legga come se fosse stata scritta da uno.
Gestisce l'output di orm e log
Le query che più hanno bisogno di formattazione sono quelle che non hanno scritto: output eloquente e activerecord, join generati da Doctrine, i mostri a riga singola nel tuo registro lenta query. L'output ORM arriva come una linea con alias generati dalla macchina (t0, t1, laravel_reserved_0), e leggerlo crudo è il modo in cui si ottengono mal di testa Il mio singolo uso più frequente del formattatore: afferrare la query da Laravel's query log o Telescope, formattarlo, e vedere effettivamente ciò che l'ORM ha deciso di fare - che è il primo passo di ogni & quot; perché è questo endpoint slow" indagine, subito prima EXPLAIN.
Tolleranza multidialetto
Real-World SQL è una famiglia di dialetti: identificatori citati dal backtick di MySQL, citazioni doppie di PostgreSQL e :: cast, parentesi quadre di SQL Server e TOP, tutto accomodante di SQLite. Un utile formattatore li gestisce tutti senza pretendere che tu dichiari prima un dialetto, preservando la sintassi specifica del dialetto anziché "correggendo" it. Lo standard SQL ANSI/ISO (ISO/IEC 9075) definisce il Common Core, ma nessuno scrive in pratica puro SQL standard e un formattatore che parla solo lo standard si strozzerebbe sul primo backtick.
Conserva la semantica, garantito
Vale la pena dichiararlo esplicitamente perché it's la paura che ferma le persone: la formattazione non può cambiare i risultati Whitespace e caso di parola chiave non sono semantici in SQL - l'unico avvertimento storico è che letterali di stringa vengono confrontati in modo distinto o meno a seconda della tua raccolta e un formattatore non tocca mai l'interno delle tue stringhe citate. L'output è la stessa istruzione, byte per byte dove i byte contano. EXPLAIN Su entrambe le versioni se vuoi vederlo: piani identici.
lato client, che conta davvero qui
SQL è la categoria di testo più sensibile che viene regolarmente incollata negli strumenti online Le query rivelano il tuo schema - nomi di tabelle, nomi di colonne, relazioni - e le query copiate dai log contengono spesso valori letterali: le e-mail in WHERE Clausole, intervalli di ID, occasionalmente qualcosa che non avrebbe mai dovuto essere in una stringa di query. la Formattatore Toolz.dev elabora tutto nel tuo browser; non viene trasmesso nulla Per SQL in particolare, I & #39; d chiamare l'elaborazione lato client un requisito, non una funzionalità - verificarlo nella scheda Rete e quindi rilassarsi.
Come utilizzare il formattatore SQL
Passaggio 1: acquisire la query
Copia l'SQL dalla sua origine: il tuo file di migrazione, una stored procedure, l'output di debug di ORM (DB::listen() o telescopio a Laravel, ActiveRecord::Base.logger in rails), il registro delle query lente o la scheda Query del tuo strumento APM. Se proveniva da un registro, potrebbe essere sfuggito a virgolette o segnaposto di parametro (?, $1) - che' va bene, i formattatori gestiscono i segnaposto e vederli chiaramente è spesso il punto.
Passaggio 2: incolla e formatta
Apri il Formattatore SQL, incolla e viene visualizzata la versione formattata Nessuna cerimonia dialettale, nessuna configurazione richiesta per ottenere un buon default Se la query include più istruzioni separate da punto e virgola, queste si formattano come istruzioni separate - utili per leggere gli script di migrazione interi.
Passaggio 3: leggilo come un recensore
Ora fai la formattazione esiste per: Scansiona il bordo sinistro. Quali tabelle sono unite e con quali tipi di join? fa il WHERE clausola hanno le condizioni che ti aspetti - e sono le AND/OR raggruppamenti tra parentesi come te ragionare si raggruppano? (Precedenza dell'operatore in put SQL AND prima OR, e i mix non parentesi dei due sono la seconda fonte di bug più grande che vedo in recensione, subito dopo i tipi di join errati.) SQL formattato rende visibili entrambi gli errori in pochi secondi.
Passaggio 4: copialo indietro - in modo selettivo
Per le query intestate nella tua base di codice, copia la versione formattata nella migrazione, il ->select() espressione grezza, il .sql file. Per il debug una tantum, non preoccuparti di andata e ritorno; la copia formattata è servita al suo scopo nel momento in cui la leggi. Un posto no Per incollare SQL formattato: di nuovo nei sistemi che archiviano le query come stringhe di configurazione in cui gli strumenti di differenza di qualcuno ora mostreranno una parete di modifiche allo spazio bianco. Formato per la lettura sempre; Riformatta le query memorizzate solo quando sei pronto a possedere la differenza.
Passaggio 5: standardizzare la convenzione del team
Il valore più grande del formattatore & #39;s è la capitalizzazione: scegli le convenzioni che puoi automatizzare - caso della parola chiave e larghezza del rientro sono le due che questo formattatore controlla direttamente - formatta tutto ciò che è nuovo sulla strada nella base di codice e l'attrito della revisione SQL diminuisce permanentemente Scrivi la scelta nella tua guida al contributo La convenzione specifica scelta conta molto meno di quella scelta da tutti che utilizzano la stessa - una frase che è vera per ogni dibattito sulla formattazione nel software e creduta da circa nessuno a metà dibattito.
Deep Dive tecnico: le convenzioni che vale la pena avere opinioni
Involucro per parola chiave. Parole chiave maiuscole, identificatori minuscoli è la convenzione dominante e la mia raccomandazione L'argomento è't tradizione - it's robustezza L'evidenziazione della sintassi scompare nei log, nei terminali, nei commenti di revisione del codice e nelle risposte Stack Overflow incollate in Slack; le parole chiave maiuscole stanno evidenziando che viaggia con il testo La controargomentazione (minuscola tutto, lascia che l'editor evidenzi) è coerente e I' ha lavorato in codebase che lo usavano felicemente What's non coerente è il mixaggio, che è ciò che ottieni senza un formattatore che impone la scelta.
Una clausola per riga, contenuto rientrato. La regola strutturale con il maggior guadagno. SELECT Inizia una linea; le sue colonne sono rientrate sotto (o sulla stessa riga se brevi). uno JOIN ottiene la sua linea con la sua ON condizione visibile - le condizioni di unione nascoste nella linea mediana sono dove si nascondono i bug di unione sbagliata. WHERE condizioni impilarne uno per linea, allineato, con AND/OR portando ogni riga in modo che la struttura logica legga verticalmente. Quando le condizioni di una query lette come una colonna, una condizione mancante è visibile come a spazio in uno schema, quali occhi umani sono eccezionalmente bravi a individuare.
La guerra delle virgole. Le virgole finali (dopo ogni colonna) lette in modo naturale; le virgole iniziali (prima di ogni colonna, all'inizio della riga) rendono la punteggiatura strutturale:
-- Trailing (most common)
SELECT
u.id,
u.email,
o.total
-- Leading (the DBA classic)
SELECT
u.id
, u.email
, o.total
I sostenitori delle virgole principali hanno due punti veramente buoni: commentare qualsiasi riga tranne la prima non rompe mai l'affermazione e una virgola mancante è immediatamente visibile al margine sinistro I sostenitori delle virgole finali ne hanno uno: assomiglia a ogni altro linguaggio che scrivo. Scrivo virgole finali e ho smesso di sentirmi male al riguardo, ma tieni presente che SQL, a differenza dei moderni JavaScript o Python, lo fa no perdona una virgola penzolante dopo la colonna finale, motivo per cui questo dibattito esiste e perché lo stile principale rifiuta di morire nei circoli DBA. Divulgazione completa: il formattatore Toolz.dev prende il lato mainstream ed emette virgole finali - non ha la modalità virgola principale, quindi se tu' sei un negozio leader impegnato di virgole questa è l'unica convenzione che ha vinto't riformatta per te Scegli uno stile house, applicalo in modo coerente e vai avanti.
Cosa non fa la formattazione. Non ottimizza. un formattato SELECT * Attraverso un join a cinque tavoli è un problema di prestazioni meravigliosamente rientrato. La formattazione è condizione indispensabile per l'ottimizzazione - non si può ragionare su una query che non si può leggere - ma il ragionamento richiede comunque EXPLAIN, Index Awareness e Conoscenza della forma dei tuoi dati. Penso alla pipeline come: formato, lettura, EXPLAIN, quindi ottimizzare. Saltare il primo passo non ti rende più veloce, fa i passi da due a quattro più lenti. La stessa disciplina applica un livello all'API, motivo per cui il Guida al formattatore JSON Fa un argomento strutturalmente identico sui carichi utili.
I commenti sopravvivono. A differenza della minificazione, la formattazione preserva i commenti - -- Commenti di riga e /* */ I blocchi passano intatti. usali. un' -- deliberately LEFT JOIN: include customers with no orders Commenta sopra un join è l'assicurazione di bug più economica mai scritta, ed è il commento di cui la mia storia dell'orrore di 340 righe aveva bisogno.
Casi d'uso comuni
Revisione del codice
SQL non formattato in una richiesta pull è una recensione che sta per accadere & #39; t - il recensore & #39; s occhi scivolano fuori dal muro di testo e l'approvazione atterra comunque Formattare la query prima di aprire il PR è cortesia di base con payoff misurabile: tipi di join, raggruppamenti di condizioni, e liste di colonne diventano individualmente visibili, il che significa che diventano individualmente revisionabili Ogni bug SQL genuino I & #39;ve catturato in revisione - l'unione sbagliata, il non parentesized OR, il DELETE manca metà del suo WHERE clausola - Ho preso perché la query è stata formattata abbastanza bene da poter essere letta riga per riga.
Debug di query generate da ORM
Gli ORM sono meravigliosi fino a quando l'endpoint non è lento, a quel punto è necessario vedere l'effettivo SQL - e l'output ORM è sempre una linea densa Formattalo e appare la storia: l'N+1 che il caricamento entusiasta ha mancato, la definizione di join the relationship silenziosamente aggiunta, il ORDER BY su una colonna non indicizzata. Nel lavoro di Laravel questo è un rituale più volte settimanale: telescopio, copia, formato, Wince, correggere il codice eloquente, ripetere. il formattatore non diagnostica nulla da solo; rende la query abbastanza leggibile le può.
Archeologia su query legacy
Ogni sistema longevo li ha: la procedura memorizzata dal 2015, la visualizzazione di reporting che nessuno osa toccare, la query incorporata in un file di configurazione con l'autore originale's formattazione (cioè, nessuno) Prima di modificare SQL legacy, formattarlo e leggerlo end to end - you'll trovare abitualmente condizioni che possono't mai essere vero, si unisce a tabelle che non ricevono più scritture e logica il team corrente's ipotesi contraddicono Formattazione primi turni & quots;query & quot legacy spaventose; in & quot; query lunga ma leggibile, & quot; che è un problema diverso e migliore.
Confronto delle versioni delle query
Quando un report's numeri cambiano tra le versioni, la domanda è & quot; cosa è cambiato nella query, & quot; e la risposta richiede differire due versioni - che funziona solo se entrambi sono formattati in modo identico prima Formattare entrambi con le stesse impostazioni, quindi eseguirli attraverso il Strumento Diff di testo: Il rumore scompare e le due linee cambiate sono da sole. Questa sequenza esatta ha trovato il mio bug di giunzione interna, alla fine. Ora lo faccio prima il giorno e mezzo di confusione invece che dopo.
Insegnamento e documentazione
SQL in tutorial, runbook e documenti interni viene letto molte più volte di quanto non venga scritto, dai lettori che hanno meno familiarità con lo schema rispetto all'autore Esempi formattati con parole chiave maiuscole e struttura one-concept-per-line sono notevolmente più facili da imparare - la struttura insegna accanto al contenuto Quando scrivo documentazione con query incorporate, ognuno passa prima attraverso il formattatore; SQL non formattato in documenti dice al lettore che l'autore ha fatto' non aspettatevi che qualcuno lo legga davvero.
Convenzioni di formattazione a confronto
| Scelta delle con | Opzione A | opzione B | la mia presa |
|---|---|---|---|
| Caso di parole chiave | SELECT (maiuscole) |
select (minuscole) |
Uppercase - sopravvive ai contesti senza evidenziare |
| caso identificativo | caso_serpente | Definizioni della tabella delle fiammiferi | Definizioni di corrispondenza; non combattere mai lo schema |
| virgole | trascinando (id,) |
guida (, id) |
Trainare, ma guidare è difendibile: scegline solo uno |
| Disposizione delle clauso | Una clausola per riga | linea singola compatta | uno per riga per qualsiasi cosa banale passata |
AND/OR collocamento |
Guidando ogni riga di condizione | Tracciando la riga precedente | Leading - la logica si legge verticalmente |
| Unisci le condizioni | ON sulla propria linea o in linea con JOIN |
Sepolto di metà linea | visibile con l'unione, sempre |
| larghezza di rientro | 2 spazi | 4 spazi | entrambi; SQL nidifica meno di JSON, quindi 4 va bene qui |
Nessuna di queste righe ha una risposta sbagliata, e quella' è proprio la trappola - perché ogni opzione è difendibile, i team le ri-litigano per sempre a meno che un formattatore non renda meccanica la decisione La mossa vincente è noiosa: scegli, configura, formatta tutto e spendi il tempo dell'argomento recuperato su cose che influenzano il piano di esecuzione Per il resto del toolkit giornaliero attorno a questo, vedi il Guida agli strumenti di codifica E il più ampio Toolkit per sviluppatori web.
FAQ
Cosa fa un formattatore SQL?
Un formattatore SQL riscrive una query's spazi bianchi, interruzioni di riga e involucro di parole chiave in una struttura coerente e leggibile - ogni clausola sulla propria riga, condizioni e colonne rientrate, parole chiave normalizzate in un caso L'istruzione's significato è intatto: i parser SQL ignorano completamente la formattazione, quindi la query formattata restituisce risultati identici con un piano di esecuzione identico La modifica è puramente per gli esseri umani che esaminano, eseguono il debug e mantengono la query.
La formattazione di SQL modifica le prestazioni della query?
No. Whitespace e keyword case non sono semantici in SQL - il database analizza entrambe le versioni nella stessa rappresentazione interna e produce lo stesso piano di esecuzione, che è possibile verificare eseguendo EXPLAIN su ciascuno. La formattazione è la precondizione per il lavoro sulle prestazioni piuttosto che per il lavoro sulle prestazioni stesso: non puoi ragionare sugli indici e unire l'ordine in una query che non puoi leggere.
Le parole chiave SQL dovrebbero essere maiuscole o minuscole?
Entrambi sono validi - le parole chiave SQL sono case-insensitive secondo lo standard - quindi questa è una convenzione di leggibilità, non una regola di correttezza Parole chiave maiuscole (Uppercase keywords)SELECT, FROM, WHERE) rimangono la scelta più comune perché agiscono come evidenziando incorporati in contesti che spogliano i colori: log, differenziali, terminali e messaggi di testo in chiaro. Qualunque cosa tu scelga, la coerenza attraverso la base di codice conta molto più della scelta stessa.
Quali sono le principali virgole in SQL e perché le persone le usano?
Stile a virgola iniziale posiziona la virgola all'inizio di ogni riga di colonna (, email) invece della fine del precedente Ai sostenitori piace perché commentare qualsiasi colonna tranne la prima non produce mai un errore di sintassi e le virgole mancanti sono immediatamente visibili al margine sinistro: vantaggi reali, poiché SQL lo fa' t tollera una virgola penzolante dopo la colonna finale come fa il moderno JavaScript Le virgole finali rimangono più comuni; entrambi funzionano se applicati in modo coerente.
Posso formattare SQL generato da un ORM come eloquent o activerecord?
Sì, e it's uno dei migliori usi di un formattatore - ORM debug output arriva come una singola linea densa con alias generati dalla macchina, e formattazione è il primo passo di diagnosticare gli endpoint lenti e problemi N + 1 Cattura la query dal tuo ORM's registrazione (Laravel Telescope, registri ActiveRecord), incollarlo nel Formattatore SQL, e leggi cosa l'ORM ha effettivamente costruito prima di raggiungere EXPLAIN.
Il formattatore funziona con la sintassi di MySQL, PostgreSQL e SQL Server?
Sì: i formattatori pratici gestiscono i principali dialetti' stranezze, preservando i backtick MySQL, gli identificatori a doppia citazione PostgreSQL e :: cast e parentesi quadre di SQL Server anziché riscriverle. Lo standard ANSI SQL definisce il core condiviso, ma nessun database di produzione parla SQL standard puro, quindi la tolleranza dialettale è un requisito per un formattatore utile su query reali.
È sicuro incollare le query di produzione in un formattatore SQL online?
Solo in uno lato client, perché SQL è insolitamente sensibile: le query espongono lo schema e le query copiate dai log spesso contengono valori letterali come e-mail o ID in WHERE clausole. la Formattatore SQL di Toolz.dev elabora tutto nel browser senza nulla di trasmesso o memorizzato - verificalo tu stesso guardando la scheda Rete mentre incolli Evita i formattatori basati su server per qualsiasi cosa dalla produzione.
La formattazione conserva i commenti SQL?
Sì, entrambi -- Commenti di riga e /* */ I commenti di blocco passano intatti, a differenza della minimizzazione, che li elimina. Ciò rende la formattazione sicura per query annotate e stored procedure in cui i commenti portano l'intento. Usalo: un commento di una riga che spiega un deliberato LEFT JOIN O una condizione insolita è la protezione più economica contro il prossimo sviluppatore "fixing" qualcosa che non era rotto.
