Formattatore SQL

SQL, una breve storia del linguaggio che stiamo formattando

SQL (Structured Query Language) è stato sviluppato in IBM da Donald D. Chamberlin e Raymond F. Boyce nei primi anni '70, originariamente come SEQUEL ("Structured English Query Language"), rinominato SQL dopo un conflitto di marchio. Il linguaggio è stato commercializzato per la prima volta dal predecessore di Oracle (Relational Software, Inc.) nel 1979, Oracle V2 è stato il primo database SQL commerciale, battendo sul mercato lo stesso DB2 di IBM. Il primo standard ANSI, ANSI SQL-86, è stato pubblicato nel 1986; la revisione molto più sostanziale SQL-92 (lo standard SQL "grande", ISO/IEC 9075:1992) ha definito gran parte della sintassi che gli utenti moderni riconoscono, sintassi JOIN, operazioni sugli insiemi, sottoquery, transazioni. Le revisioni successive hanno aggiunto funzionalità object-relational (SQL:1999), supporto XML (SQL:2003), funzioni window e CTE (SQL:2003 e 2008), query temporali (SQL:2011), supporto JSON (SQL:2016, ampliato in SQL:2023). Ogni grande vendor di database implementa il proprio dialetto, MySQL, PostgreSQL, SQLite, Microsoft SQL Server (T-SQL), Oracle (PL/SQL), DuckDB (SQL analitico compatibile con PostgreSQL), BigQuery, Snowflake, Redshift, ClickHouse, Databricks SQL, tutti condividono il nucleo SQL-92 ma divergono su funzioni, estensioni di sintassi e liste di parole riservate. Un buon formattatore rispetta il dialetto che sta formattando perché lo stesso identificatore potrebbe essere una keyword in un dialetto e un nome di colonna legale in un altro.

Convenzioni che rendono SQL leggibile

Diverse convenzioni sono diventate standard nelle guide di stile SQL, quella di Mozilla, l'SQL Style Guide ampiamente citata di Simon Holywell, le convenzioni del data team di GitLab, lo stile raccomandato di dbt. Keyword in MAIUSCOLO (SELECT, FROM, WHERE, JOIN) contro identificatori (nomi di tabella e colonna) in minuscolo o snake_case è la convenzione dominante. Alcune guide di stile sostengono l'opposto (le keyword in minuscolo sono più facili da digitare e leggere), e la documentazione del dialetto per PostgreSQL stesso usa keyword in minuscolo dappertutto, ma le keyword in MAIUSCOLO vincono nella maggior parte delle codebase professionali perché rendono visibile a colpo d'occhio la struttura del linguaggio. Ogni clausola maggiore sulla propria riga: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, ognuna inizia una nuova riga allo stesso livello di indentazione. Condizioni JOIN indentate sotto ON: la keyword JOIN sulla propria riga, la keyword ON sulla riga successiva indentata di un livello. Comma-first o comma-last nelle liste di colonne è una vecchia disputa stilistica; comma-first (ogni riga di colonna inizia con la virgola) rende l'aggiunta/rimozione di colonne in diff più puliti e protegge contro l'errore di sintassi della virgola finale, ma sembra visivamente insolito a molti. Comma-last è più comune nel codice di produzione. Indentazione delle sottoquery: le query annidate indentate di un livello in più rispetto al loro genitore. Clausole CTE (WITH): ogni CTE con nome sulla propria riga, il corpo indentato sotto l'AS, la query principale in fondo allineata a sinistra.

Quando ti servirà un formattatore SQL

• Leggere query loggate da un ORM. Hibernate, Sequelize, ActiveRecord, Prisma, SQLAlchemy, Django ORM, generano tutti SQL programmaticamente e lo emettono come una singola riga densa nei log dell'applicazione. Per fare debug di "perché questa query è lenta", incolla l'SQL loggato nel formattatore e leggi cosa l'ORM ha effettivamente prodotto. Il risultato è spesso illuminante ("oh, è un CROSS JOIN dove mi aspettavo un INNER").
• Code review su PR di database. Una migrazione SQL o un cambiamento di stored procedure è molto più facile da rivedere quando formattato in modo coerente. Passa il file attraverso il formattatore prima di fare commit così il diff è strutturale, non rumore di spazi.
• Leggere piani EXPLAIN insieme alla query. Quando ottimizzi una query lenta, leggi l'output di EXPLAIN, poi rileggi la query per trovare il riferimento alla tabella in cima al piano. Una query formattata rende il riferimento incrociato istantaneo.
• Incollare SQL in ticket, doc, Slack. Una query formattata si legge pulita; una query minificata su una sola riga è illeggibile in qualsiasi contesto stretto. Formatta prima di condividere.
• Riformattare query legacy con keyword a caso misto. Una codebase di 15 anni fa dove SELECT a volte era scritto Select, a volte select, a volte SELECT si legge meglio dopo che il formattatore normalizza tutto in una convenzione.
• Pulire query esportate da strumenti BI. Looker, Mode, Metabase, Tableau e strumenti simili ti permettono di copiare l'SQL sottostante ma lo emettono in qualunque formato ad-hoc generino. Formatta prima di leggere.

L'ecosistema dei formattatori SQL

Per i flussi di lavoro a riga di comando e integrati nell'editor, esistono diverse opzioni mature. sql-formatter (pacchetto npm, originariamente di Andriy Isayev, ora mantenuto da un team della comunità) è il formattatore SQL dominante dell'ecosistema JavaScript, supporta MySQL, PostgreSQL, SQLite, Standard SQL, BigQuery, Redshift, Snowflake, Spark, TiDB, MariaDB e diversi altri dialetti. pg_format (Gilles Darold) è il formattatore canonico specifico per PostgreSQL, scritto in Perl e distribuito con il popolare servizio web pgFormatter. Poor Man's T-SQL Formatter (Tao Klerks, 2011) si rivolge specificamente al dialetto T-SQL di Microsoft SQL Server. sqlparse (Andi Albrecht) è la libreria Python standard, usata da Django per l'analisi delle query e da innumerevoli script di data engineering. SQLFluff è il moderno linter-e-formattatore che si integra con i progetti dbt e i flussi di lavoro analitici. DataGrip di JetBrains e il plugin SQL per IntelliJ IDEA includono un formattatore sofisticato consapevole del dialetto; SQLTools di VS Code e diverse altre estensioni avvolgono la libreria sql-formatter di npm. Per progetti con una pipeline di build, lo schema moderno è "format on save nell'editor + un controllo CI che fa fallire la build se i file SQL sono mal formattati", lo stesso modello di Prettier per JavaScript o Black per Python.

Differenze di dialetto che contano per la formattazione

La maggior parte dei formattatori SQL funziona attraverso i dialetti con regolazioni minori, ma una manciata di differenze richiede al formattatore di sapere quale dialetto sta leggendo. Identificatori tra apici: SQL standard usa doppi apici ("order"); MySQL usa backtick (`order`) per default e rispetta i doppi apici solo in modalità ANSI; SQL Server usa parentesi quadre ([order]). Concatenazione di stringhe: SQL standard usa ||; MySQL usa CONCAT() o il raramente visto || in modalità ANSI; SQL Server usa +. Paginazione: MySQL/PostgreSQL/SQLite usano LIMIT/OFFSET; SQL Server usa TOP o OFFSET FETCH; Oracle usa FETCH o ROWNUM. Auto-incremento: AUTO_INCREMENT in MySQL, SERIAL o IDENTITY in PostgreSQL, IDENTITY in SQL Server, AUTOINCREMENT in SQLite. Le liste di parole riservate divergono, una colonna chiamata rank ha bisogno di apici in PostgreSQL (dove RANK è una keyword di funzione window) ma va bene come identificatore in MySQL. Un formattatore che non conosce il dialetto può rompere query valide aggiungendo apici inappropriati. L'output "Format SQL" da un formattatore generico è solitamente corretto per la forma standard SELECT/INSERT/UPDATE/DELETE; per la sintassi specifica del vendor (funzioni window, hint, funzioni di sistema), controlla a campione l'output rispetto alla documentazione del tuo dialetto.

Privacy: perché il solo browser conta soprattutto per SQL

Le query SQL sono tra il testo più sensibile in qualsiasi organizzazione: espongono nomi di tabella interni (che rivelano la tassonomia dei prodotti), nomi di colonna (che rivelano il data model), valori di filtro (che possono includere ID utente reali, indirizzi email, ID di business), credenziali letterali incorporate negli schemi più vecchi e la struttura delle analitiche che l'azienda potrebbe considerare proprietarie. I formattatori SQL lato server prendono una copia di ogni query nei loro log. Questo formattatore funziona interamente nel tuo browser tramite JavaScript, verifica nel pannello Network di DevTools mentre clicchi Formatta (nessuna richiesta parte) o metti la pagina offline (modalità aereo) dopo il caricamento e il formattatore continua a funzionare. Sicuro per query di produzione contenenti nomi di tabella reali e valori di filtro PII, SQL analitico interno, pipeline ETL o qualsiasi query che non vorresti vedere copiata sul disco rigido di uno sconosciuto.

Domande frequenti

Il formattatore può mettere in maiuscolo le keyword SQL automaticamente?

Sì, l'interruttore Keywords controlla il caso. MAIUSCOLO è la convenzione professionale dominante perché rende visibile a colpo d'occhio la struttura del linguaggio (SELECT, FROM, WHERE risaltano dagli identificatori); minuscolo è preferito da alcune guide di stile (la documentazione di PostgreSQL stessa usa minuscolo dappertutto) sulla base che è più facile da leggere e più veloce da digitare. Entrambi funzionano finché il tuo team ne sceglie uno e lo usa coerentemente. La capitalizzazione non ha effetto sul comportamento della query, le keyword SQL sono case-insensitive al momento del parse.

Come personalizzo l'indentazione?

La rullante Indent supporta 2 spazi (la convenzione web moderna dominante), 4 spazi (ancora comune nei vecchi negozi Java e .NET) o caratteri tab. 2 spazi tendono a vincere nelle codebase più nuove e per SQL specificamente perché l'annidamento profondo di sottoquery sta più comodamente entro un limite di riga di 100 caratteri. Allinea con qualsiasi convenzione il tuo team già usi; la coerenza conta più della scelta specifica.

Funziona con query grandi?

Sì, poiché la formattazione avviene nel tuo browser, il soffitto pratico è la memoria disponibile del tuo dispositivo. Centinaia di righe di SQL si formattano in molto meno di un secondo; query di più migliaia di righe (tipiche nell'ETL di data-warehouse) funzionano ma possono congelare brevemente la scheda mentre il parser cammina nella struttura. Per la riformattazione in batch di un intero repository SQL, gli strumenti a riga di comando (sql-formatter tramite npm, pg_format per PostgreSQL, SQLFluff per progetti dbt) sono più appropriati.

Il formattatore riconoscerà il mio dialetto SQL specifico?

Gestisce correttamente le forme comuni SELECT/INSERT/UPDATE/DELETE/JOIN/CTE/sottoquery attraverso MySQL, PostgreSQL, SQLite, T-SQL e ANSI SQL standard. La sintassi vendor-specifica, le clausole di funzione window, gli statement MERGE, gli hint specifici del dialetto, le funzioni di sistema, gli operatori di array stile PostgreSQL, i metodi XML T-SQL, può formattarsi imperfettamente. Controlla a campione l'output ed esegui la query formattata attraverso il tuo database per confermare che si analizzi correttamente prima di fare commit.

Il mio SQL viene caricato?

No. La formattazione avviene interamente nel tuo browser, le query incollate non lasciano mai il tuo dispositivo. Verifica nel pannello Network di DevTools mentre clicchi Formatta (nessuna richiesta parte) o metti la pagina offline (modalità aereo) dopo il caricamento. Sicuro per query di produzione contenenti nomi di tabella sensibili, valori di filtro PII o qualsiasi SQL coperto da NDA o regolamentazione di compliance.

Strumenti correlati