ToolZen ToolZen
Developer formatter client

SQL Formatter

Format SQL queries with consistent indentation and keyword casing. Supports MySQL, PostgreSQL, SQL Server, Oracle, SQLite, BigQuery and Spark SQL.

Advertisement (Top Banner)
Indentation
Keywords
Advertisement (Bottom)

Una query che arriva come un'unica riga da 400 caratteri è illeggibile, e le query illeggibili nascondono bug. Questo strumento interpreta il tuo SQL e lo dispone con ogni clausola sulla sua riga. Interpreta invece di limitarsi a indentare, ed è per questo che sa dirti quando qualcosa non va — e per questo scegliere il dialetto giusto conta.

Il selettore di dialetto non è un ornamento

SQL è uno standard che nessuno implementa esattamente, e le differenze partono da qualcosa di elementare come mettere tra virgolette un nome. MySQL e MariaDB racchiudono gli identificatori nei backtick. PostgreSQL usa le virgolette doppie e rifiuta i backtick seccamente. SQL Server usa le parentesi quadre. Una query scritta per un motore e interpretata come un altro non si formatta solo in modo strano: fallisce.

Lo puoi vedere qui. Incolla una query MySQL con nomi di colonna tra backtick, seleziona PostgreSQL, e l'output si svuota: il parser si è correttamente rifiutato di leggere i backtick come PostgreSQL, perché non lo sono. È lo strumento che ti dice una cosa vera sulla tua query, non che si rompe.

Le differenze vanno più a fondo delle virgolette. Il limite di righe è LIMIT in MySQL, PostgreSQL e SQLite, TOP in SQL Server, e FETCH FIRST nello standard vero. La concatenazione di stringhe è || quasi ovunque e CONCAT() in MySQL, dove || significa OR logico a meno che non si attivi una modalità specifica. Se stai spostando una query tra motori, sono queste le giunture dove si crepa.

La formattazione controlla la sintassi, non la verità

Dai a questo strumento una query piena di sciocchezze e ti mostrerà un errore, perché interpreta davvero il testo. È utile, ed è anche il limite di ciò che può dirti. Una query può essere perfettamente ben formata e comunque catastroficamente sbagliata.

Non può sapere se le tue tabelle esistono, se la colonna su cui hai fatto il join è indicizzata, se quel JOIN restituirà le righe che ti aspetti o cinquanta milioni. Una formattazione pulita non è una revisione del codice. Quello che la formattazione ti compra è la possibilità di vedere la forma della query — e una volta che una query è distesa, una condizione di join mancante o una WHERE che ha perso le parentesi tende a diventare visibile in un modo in cui non lo è mai su una riga lunga.

Un formattatore non è uno strumento di sicurezza

Merita dirlo chiaramente perché la confusione è reale. Formattare il tuo SQL non fa assolutamente nulla contro la SQL injection. Non codifica niente, non valida niente, e una query costruita incollando input utente dentro una stringa è esattamente pericolosa quanto lo era prima: è solo più leggibile mentre ti cancella la tabella.

L'unica difesa vera sono le query parametrizzate: il testo SQL e i valori viaggiano separati, quindi un valore non può mai essere reinterpretato come sintassi. Ogni driver serio lo supporta. Se ti ritrovi a cercare una funzione di escape, di solito è il segno che la query viene costruita al contrario.

Le parole chiave non distinguono maiuscole; gli identificatori sono la trappola

SELECT, select e SeLeCt sono la stessa parola chiave per ogni motore, quindi l'opzione maiuscolo qui è puro stile: una convenzione diffusa che rende la struttura scorribile a occhio, e niente più. Nessuno ti ringrazierà per le parole chiave minuscole, e nemmeno si romperà niente.

È il caso degli identificatori dove vivono i bug veri. PostgreSQL ripiega gli identificatori non quotati in minuscolo, quindi SELECT MyColumn in realtà chiede mycolumn — e se hai creato la colonna come "MyColumn" con le virgolette, non verrà trovata. Lo standard dice che gli identificatori si ripiegano in maiuscolo, quindi qui PostgreSQL è tecnicamente non conforme e tutti hanno silenziosamente accettato di conviverci.

MySQL è ancora più strano: se i nomi delle tabelle distinguano maiuscole e minuscole dipende dal filesystem sotto il server. Le tabelle sono file, quindi su Linux distinguono e su Windows e macOS no. È il meccanismo dietro una classe di bug specifica e miserabile: una query che funziona sul Mac di uno sviluppatore e fallisce in produzione su Linux, senza niente nel codice a spiegarlo.

Domande frequenti

La mia query viene inviata a un server?

No. Questo strumento è marcato "client": il parser gira nella scheda del tuo browser e l'SQL non lascia mai la macchina. Qui conta più che per la maggior parte degli strumenti, perché le query vere portano nomi di tabelle, nomi di colonne e spesso valori letterali dalla produzione: la forma del tuo schema è informazione che probabilmente non vuoi consegnare a uno sconosciuto.

Formattare cambia quello che fa la mia query?

No. Gli spazi tra i token SQL non sono significativi, quindi la query riformattata è la stessa query. L'unica cosa a cui badare sono i letterali stringa: il testo tra virgolette è dato, e un formattatore deve lasciarlo intatto. Questo lo fa. Se ti capita un formattatore che reindenta dentro una stringa, smetti di usarlo immediatamente.

Perché la mia query dà errore qui ma gira bene sul mio database?

Molto probabilmente il dialetto. Seleziona il motore che usi davvero invece di Standard SQL: i motori accettano parecchie cose che lo standard non prevede. Può anche essere un'estensione genuinamente specifica del motore che il parser non modella, nel qual caso la query va bene e lo strumento semplicemente non è l'autorità in materia. Il tuo database sì.

Devo usare le parole chiave in maiuscolo?

Per il motore non fa alcuna differenza. La convenzione esiste perché separa il linguaggio dai tuoi dati a colpo d'occhio: in SELECT name FROM users, le parole maiuscole sono SQL e quelle minuscole sono tue. La maggior parte dei team la segue, e la regola utile è adeguarsi a ciò che c'è già nel tuo codice invece di avere un'opinione.

Può formattare una stored procedure o uno script di migrazione grosso?

Gestisce più istruzioni e te le separa. Le estensioni procedurali — PL/pgSQL, le routine di MySQL, il control flow di T-SQL — sono un linguaggio diverso appoggiato sopra SQL, e il supporto varia col dialetto. Se il corpo di una procedura torna indietro storpiato, è quello il confine che hai toccato, e la risposta è formattare le query al suo interno invece dell'intera routine.