Convertitore gratuito da SQL a JSON

Converti istruzioni SQL CREATE TABLE in schema JSON. Estrai all'istante i nomi delle colonne, i tipi e i vincoli.

I tuoi dati non lasciano mai il tuo dispositivo

Informazioni sulla conversione SQL → JSON

Questo strumento analizza le istruzioni SQL CREATE TABLE e le converte in formato schema JSON. Estrae i nomi delle colonne, i tipi di dati (INT, VARCHAR, TEXT, BOOLEAN, DATE, TIMESTAMP, DECIMAL) e i vincoli (NOT NULL, PRIMARY KEY, valori DEFAULT). L'output JSON è adatto per la documentazione di API, la progettazione di database o gli strumenti di migrazione.

Tipi di dati SQL supportati

Domande frequenti

Quali dialetti SQL sono supportati?

Questo convertitore gestisce la sintassi SQL standard usata da MySQL, PostgreSQL, SQL Server e SQLite. Le funzionalità specifiche di un dialetto possono non essere completamente riconosciute.

Gestisce vincoli complessi?

Il convertitore riconosce NOT NULL, PRIMARY KEY, DEFAULT e le informazioni di tipo di base. I vincoli complessi come CHECK o FOREIGN KEY sono memorizzati come annotazioni di testo.

Posso usare l'output JSON direttamente?

Sì! L'output JSON è formattato per la leggibilità e può essere usato in schemi di API, interfacce TypeScript o generatori di documentazione.

Schema, non dati, cosa fa questo strumento

Questo convertitore prende un'istruzione SQL CREATE TABLE ed emette uno JSON Schema: una descrizione delle colonne, dei tipi e dei vincoli di base, adatta ai contratti delle API, alla generazione di tipi TypeScript e alle migrazioni verso archivi documentali. Non converte in JSON le righe INSERT né gli insiemi di risultati delle query. L'interesse di ricerca per «SQL to JSON» si divide all'incirca a metà tra queste due esigenze; se sei arrivato aspettandoti la conversione da riga a oggetto, ti servirà uno strumento diverso. Il percorso di conversione dello schema è il caso rivolto agli sviluppatori: hai una definizione di tabella e vuoi una descrizione strutturata della sua forma che un altro strumento possa consumare.

Una breve storia di SQL

SQL fu progettato al San Jose Research Laboratory di IBM nei primi anni '70 da Donald D. Chamberlin e Raymond F. Boyce. Il nome originale era SEQUEL: Structured English Query Language, concepito come un'interfaccia di più alto livello per il database relazionale sperimentale System R di IBM. Il modello relazionale stesso era stato pubblicato nel 1970 da Edgar F. Codd; il contributo di Chamberlin e Boyce fu una sintassi che gli analisti comuni potevano leggere, modellata su clausole in inglese naturale (SELECT … FROM … WHERE …) anziché sui simboli algebrici di Codd. Boyce (che avrebbe anche dato il suo nome alla forma normale di Boyce-Codd) morì nel 1974 all'età di 26 anni, prima che il linguaggio che aveva co-inventato vedesse il rilascio commerciale. Il nome fu cambiato in SQL nel 1975 a causa di un conflitto di marchio con il marchio SEQUEL di Hawker Siddeley, anche se la pronuncia originale «sequel» persiste negli Stati Uniti accanto a quella internazionale «ess-cue-ell».

L'ANSI standardizzò SQL nel 1986 (SQL-86), l'ISO ratificò una versione essenzialmente identica nel 1987 come ISO/IEC 9075, e da allora lo standard è stato rivisto ogni tre-cinque anni: SQL-92 (ancora la base che la maggior parte dei tutorial presuppone), SQL:1999 (query ricorsive, trigger), SQL:2003 (tipo XML, MERGE), SQL:2011 (tabelle temporali), SQL:2016 (supporto JSON), e più recentemente SQL:2023 (array multidimensionali, query su grafi di proprietà). Nonostante ondate di tecnologie concorrenti (database a oggetti negli anni '90, NoSQL alla fine degli anni 2000, data lake negli anni 2010) SQL è persistito come linguaggio di query dominante per i dati strutturati per oltre cinquant'anni. Entro il 2024, persino la maggior parte delle piattaforme NoSQL ha reintrodotto SQL o livelli simili a SQL (il CQL di Cassandra, la fase di aggregazione $sql di MongoDB, il PartiQL di DynamoDB, Spark SQL, Trino, DuckDB, BigQuery, Snowflake), confermando la previsione di Mike Stonebraker secondo cui il linguaggio sarebbe sopravvissuto a qualsiasi singolo motore di archiviazione.

JSON in un paragrafo

JSON (JavaScript Object Notation) fu specificato da Douglas Crockford nel 2001, derivato da un sottoinsieme della sintassi dei letterali oggetto di JavaScript, e standardizzato come ECMA-404 nel 2013 e IETF RFC 8259 nel 2017. Ha solo sei tipi di valore (stringa, numero, booleano, null, array, oggetto) e nessun concetto nativo di date, decimali, binario o schemi. Lo JSON Schema (una specifica separata, attualmente alla bozza 2020-12) sovrappone la validazione strutturale e di tipo. Il valore dello JSON Schema per questo convertitore: è un formato portatile e indipendente dallo schema che quasi ogni generatore di codice e libreria di validazione moderni comprendono.

La conversione meccanica

Un input rappresentativo:

CREATE TABLE users (
  id INT PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  signup_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  is_active BOOLEAN DEFAULT TRUE
);

Si mappa a:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "users",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "maxLength": 255 },
    "signup_at": { "type": "string", "format": "date-time" },
    "is_active": { "type": "boolean", "default": true }
  },
  "required": ["id", "email"]
}

Passo dopo passo: tokenizza l'input, individua CREATE TABLE e il nome della tabella, trova l'elenco di colonne tra parentesi, dividi le definizioni delle colonne sulle virgole di primo livello (rispettando le parentesi annidate per cose come DECIMAL(10,2) o CHECK (x > 0)), analizza ogni colonna in nome + tipo + modificatori, e mappa il tipo SQL al tipo JSON Schema più vicino. NOT NULL diventa l'appartenenza all'array required. DEFAULT diventa un valore default. PRIMARY KEY di solito diventa un'annotazione o l'appartenenza a required. CHECK, FOREIGN KEY, UNIQUE e gli indici tipicamente diventano annotazioni testuali perché lo JSON Schema non ha un equivalente diretto.

Il problema dei dialetti

SQL è notoriamente una famiglia di dialetti, non un singolo linguaggio. Persino la virgolettatura di base degli identificatori differisce:

Anche i nomi dei tipi divergono. INT(11) in MySQL è un suggerimento di larghezza di visualizzazione che PostgreSQL rifiuta. SERIAL in PostgreSQL è un'abbreviazione di INT NOT NULL AUTO_INCREMENT PRIMARY KEY; IDENTITY svolge lo stesso ruolo in SQL Server; SQLite usa AUTOINCREMENT. BOOLEAN è TINYINT(1) dietro le quinte in MySQL. I tipi geografici (GEOMETRY, POINT), i tipi di colonna JSON (JSON, JSONB), i tipi array (l'INTEGER[] di PostgreSQL) e i tipi vettoriali full-text (VECTOR(1536) in pgvector) non hanno equivalente JSON Schema e finiscono come annotazioni stringa opache. I dati binari BLOB e BYTEA non hanno rappresentazione JSON nativa; la prassi standard è la stringificazione in base64 con un suggerimento contentEncoding.

Tipi SQL contro tipi JSON, la mancata corrispondenza di impedenza

SQL ha un ricco sistema di tipi; JSON ha sei tipi di valore e nessuno schema. Vale la pena sapere:

Quando ricorreresti a questo

Alternative moderne

Altre domande

E se il mio CREATE TABLE ha vincoli FOREIGN KEY?

Lo JSON Schema non ha un concetto nativo di chiave esterna. La rappresentazione più pulita è un'annotazione personalizzata (ad es., una proprietà x-foreign-key non standard) che annota la tabella e la colonna referenziate. Questo convertitore preserva la relazione come nota testuale nell'output; se hai bisogno di una modellazione dei riferimenti completamente formale, il $ref dello JSON Schema più un blocco di definizioni separato è la soluzione più adatta, ma è scomoda per i casi molti-a-molti. Per una modellazione relazionale più ricca prendi in considerazione DBML o Atlas HCL.

Perché l'output non include i vincoli CHECK?

Lo JSON Schema può esprimere molti vincoli CHECK semplici, CHECK (age >= 0) diventa {"minimum": 0}, CHECK (status IN ('a','b')) diventa {"enum": ["a","b"]}: ma le espressioni SQL arbitrarie nelle clausole CHECK (chiamate di funzione, join, sottoquery) non hanno equivalente JSON Schema. Il convertitore riconosce i casi semplici e preserva i vincoli complessi come annotazioni testuali anziché eliminarli silenziosamente.

Posso convertire le righe INSERT in JSON?

Non con questo strumento, gestisce solo la conversione a livello di schema (CREATE TABLE). Per la conversione a livello di riga, l'approccio giusto è di solito quello nativo del database: il SELECT row_to_json(t) FROM tbl t di PostgreSQL, il JSON_OBJECT() di MySQL, o l'esportazione in CSV e l'uso di uno strumento da CSV a JSON. mysqldump --xml convogliato attraverso un convertitore da XML a JSON è un altro percorso ben battuto.

Perché BIGINT è un problema in JSON?

Il JSON.parse di JavaScript usa i double IEEE 754, che possono rappresentare esattamente solo gli interi fino a 2^53 = 9.007.199.254.740.992. I numeri superiori a quello perdono precisione. Il BIGINT di SQL arriva fino a 2^63 ≈ 9,2 quintilioni, ben oltre l'intervallo sicuro degli interi JSON. La convenzione multipiattaforma per trasportare in sicurezza BIGINT attraverso JSON è serializzarlo come stringa e analizzarlo con BigInt a destinazione; molte API (gli ID dei tweet di Twitter / X, gli ID di Stripe, il bigserial di PostgreSQL) fanno esattamente questo.

Viene inviato qualcosa a un server?

No. Il parser viene eseguito nel tuo browser; l'output JSON è costruito localmente. L'SQL incollato non lascia mai il tuo dispositivo, il che è importante se le tue istruzioni CREATE TABLE contengono nomi di colonna proprietari, convenzioni interne delle tabelle o altri dettagli che non vuoi vengano registrati. La pagina funziona offline una volta caricata.

Strumenti correlati

Formattatore JSON

Formatta, minifica e valida JSON all'istante.

Formattatore SQL

Formatta e abbellisce le query SQL.

Formattatore XML

Formatta e valida i documenti XML.