Che cos’è un file SQL?

SQL è un formato di testo semplice che si apre in qualsiasi editor. Si usa per spostare dati fra programmi e l'archiviazione.

L’estensione è .sql e il nome per esteso è SQL Insert Statements. Contano entrambi meno di ciò che il file può contenere, ed è di questo che parla il resto della pagina.

Risale al 1986. La specifica è ISO/IEC 9075.

A un formato rimasto leggibile così a lungo si può affidare qualcosa che vuoi ritrovare fra dieci anni.

È pubblicata per intero, quindi la si può implementare partendo dal documento invece che per osservazione: è per questo che il formato compare in così tanti programmi, ed è per questo che file scritti vent’anni fa si aprono ancora. Una specifica pubblicata però non è la stessa cosa di una esente da royalty: dove un formato incapsula un codec, le licenze sui brevetti restano una questione a parte che lo standard non risolve.

SQL ha una sintassi per i commenti, ed è la differenza fra un file che cura una persona e uno che scrive un programma. I commenti sono la prima cosa che si perde convertendo in un formato che non li ha, e nessuno ti avvisa.

PostgreSQL, MySQL e DBeaver lo leggono, e così fanno quasi tutti i programmi dello stesso tipo.

Quando un file non si apre, il formato è raramente il problema: più spesso è il programma a essere più vecchio di lui. Convertire in qualcosa di più vecchio è la via d’uscita affidabile, ed è a questo che serve il resto di questo sito.

Nessun browser lo legge.

È di gran lunga il motivo più comune per convertirlo: non che il formato sia scadente, ma che il posto in cui vuoi mostrare il file non sappia leggerlo.

SQL è pensato per essere aperto e modificato. Tieni il file in questo formato per tutto il tempo in cui il lavoro va avanti, ed esporta da lì ogni volta che serve una copia finita.

SQL è un linguaggio di interrogazione standardizzato dal 1986. Un file .sql è un file di testo con dentro istruzioni, e questo è tutto il formato: non c’è intestazione, non c’è struttura e non c’è modo di sapere dall’estensione cosa fa un file specifico. Può creare tabelle, inserire un milione di righe, modificare uno schema o semplicemente salvare tre query che qualcuno voleva non perdere.

Nella pratica ciò che si scambia è di due tipi. Un dump è un database o una tabella scritti come istruzioni che li ricreano altrove. Una migrazione è uno script che cambia uno schema in modo controllato. Entrambi sono testo e si aprono in qualsiasi editor, e confonderli è il modo abituale in cui uno script pensato per aggiungere una colonna finisce per cancellare una tabella.

Di solito tre cose in quest’ordine. Un’istruzione che elimina la tabella se esiste, motivo per cui eseguire un dump contro un database vivo non è un’azione reversibile. Un CREATE TABLE che definisce le colonne e i loro tipi. E poi le righe, come istruzioni INSERT: a volte una per riga e a volte qualche centinaio raggruppate in un’unica istruzione, il che carica molto più in fretta e si legge molto peggio.

Intorno a questo, un dump reale aggiunge lavoro accessorio: dichiarazioni del set di caratteri, impostazioni che sospendono la ricostruzione degli indici mentre entrano i dati, e una transazione che avvolge il tutto perché un fallimento a metà caricamento non lasci nulla a metà. Questa parte accessoria è specifica di ciascun database, ed è il motivo principale per cui un dump di uno non entra in un altro.

Lo standard definisce un nucleo e ogni database lo estende. Il modo di racchiudere gli identificatori cambia: apici inversi in MySQL, virgolette doppie in PostgreSQL, parentesi quadre in SQL Server. Le chiavi autoincrementali si scrivono in tre modi diversi. Le funzioni di data, quelle di testo, il trattamento dei booleani e i nomi dei tipi stessi divergono.

Quindi un dump di MySQL non entra in PostgreSQL, e l’errore che restituisce è di solito una lamentela di sintassi alla riga quattro e non una spiegazione del perché. Tradurre da un dialetto all’altro è lavoro vero e piuttosto meccanico; se ciò che spostate sono dati e non uno schema, passare per il CSV è molto spesso più veloce e più affidabile che tradurre l’SQL.

Da terminale, ogni database porta il proprio client e l’invocazione è breve: psql per PostgreSQL, il client mysql per MySQL e MariaDB, sqlite3 per SQLite, tutti e tre prendono il file come input. È di gran lunga la via più rapida per un dump grande, perché uno strumento grafico che carica l’intero file in memoria si blocca appena supera qualche centinaio di megabyte.

Due cose da fare prima di eseguirlo. Leggere l’inizio del file per vedere se cancella qualcosa. E creare prima il database di destinazione se il dump non lo crea da solo, perché un dump scritto per un nome di database specifico non se ne inventa un altro in silenzio.

Di solito è una fra quattro. Un limite di dimensione dell’istruzione o del pacchetto, che scatta con un INSERT raggruppato che porta migliaia di righe, ed è del server e non del file. Un timeout esaurito in un client grafico, che nella riga di comando non ha equivalente. Un disallineamento di set di caratteri, che appare come testo rovinato invece che come errore e conviene individuare presto. O una chiave esterna che rifiuta righe arrivate prima della tabella a cui puntano.

L’ultima è la più frequente e la meno evidente. I dump di solito la risolvono disattivando il controllo delle chiavi durante il caricamento, e un dump modificato a mano — qualche tabella estratta da un file più grande — perde quella protezione. Caricare nell’ordine delle dipendenze, o restituire quell’involucro al file, è il rimedio.

Un dump serve a ricreare un database. Se ciò che volete sono i dati — per analizzarli, per aprirli in un foglio di calcolo, per darli a chi non amministra alcun database — il CSV è un contenitore migliore, e il Parquet lo è ancora di più appena la dimensione inizia a farsi sentire.

Vale la pena conoscere anche la direzione opposta. Convertire una tabella in istruzioni INSERT è il modo abituale di inserire dati in un database a cui non avete connessione diretta, situazione molto comune negli hosting condivisi: nessuna porta aperta, ma una console di query che esegue volentieri il file che le incollate.

È testo, quindi lo apre qualsiasi editor. Per qualcosa che eseguirete vale la pena usarne uno che capisca la sintassi, perché colorerà le istruzioni e renderà visibile una virgoletta non chiusa prima che la trovi il database.

Un dump può essere enorme, e il modo sensato di ispezionarne uno da diversi gigabyte è guardare le prime e le ultime decine di righe invece di aprirlo tutto. Le prime dicono il dialetto, il set di caratteri e se qualcosa viene cancellato; le ultime dicono se il dump è terminato, il dato più utile che si possa sapere di un file inviato da qualcun altro.

Quando qui si converte una tabella — un CSV, un JSON, un foglio di calcolo — in .sql, ciò che esce sono unicamente istruzioni INSERT INTO … VALUES …; Non c’è CREATE TABLE, non ci sono tipi, non ci sono chiavi né indici. In altre parole: il file carica dati in una tabella che deve già esistere, con le colonne già definite, e non la costruisce per voi. È il modo giusto di capirlo prima di eseguirlo contro qualcosa.

Tre altri dettagli da sapere. Il nome della tabella deriva dal nome del file di origine, sanificato. I booleani sono scritti TRUE e FALSE, il che non è valido in tutti i dialetti. E gli identificatori non vengono racchiusi tra virgolette, quindi un nome di colonna che coincide con una parola riservata darà problemi. Se i dati di partenza sono annidati, vengono appiattiti in colonne con il nome separato da punti, come verso CSV.

Qui non esiste alcuna conversione che parta da un .sql: né costruita né in programma, ed è l’unico formato del catalogo di cui si può dire questo, perché è l’unico dichiarato illeggibile in entrata. Si può convertire una tabella in un file .sql e non il contrario, e la ragione è che un insieme di istruzioni INSERT non è una tabella: è un programma che produrrebbe una tabella se qualcosa lo eseguisse, con il suo dialetto, le sue dipendenze e il suo ordine.

Per recuperare i dati da un dump che avete già, la via è quella di sempre: caricarlo nel database corrispondente ed esportare da lì in CSV. Richiede più passaggi ed è l’unica versione di quell’operazione che non indovina nulla.