Conversor gratuito de SQL para JSON

Converta instruções SQL CREATE TABLE em schema JSON. Extraia instantaneamente nomes de colunas, tipos e restrições.

Seus dados nunca saem do seu dispositivo

Sobre a conversão SQL → JSON

Esta ferramenta analisa as instruções SQL CREATE TABLE e as converte para o formato schema JSON. Ela extrai nomes de colunas, tipos de dados (INT, VARCHAR, TEXT, BOOLEAN, DATE, TIMESTAMP, DECIMAL) e restrições (NOT NULL, PRIMARY KEY, valores DEFAULT). A saída JSON serve para documentação de API, design de banco de dados ou ferramentas de migração.

Tipos de dados SQL suportados

Perguntas frequentes

Quais dialetos SQL são suportados ?

Este conversor gerencia a sintaxe SQL padrão usada pelo MySQL, PostgreSQL, SQL Server e SQLite. Recursos específicos de um dialeto podem não ser totalmente reconhecidos.

Ele lida com restrições complexas ?

O conversor reconhece NOT NULL, PRIMARY KEY, DEFAULT e as informações de tipo básicas. Restrições complexas como CHECK ou FOREIGN KEY são armazenadas como anotações em texto.

Posso usar a saída JSON diretamente ?

Sim ! A saída JSON é formatada para a legibilidade e pode ser usada em schemas de API, interfaces TypeScript ou geradores de documentação.

Esquema, não dados: o que esta ferramenta faz

Este conversor recebe uma instrução SQL CREATE TABLE e emite um JSON Schema: uma descrição das colunas, dos tipos e das restrições básicas, adequada para contratos de API, geração de tipos TypeScript e migrações para bancos de documentos. Ele não converte linhas de INSERT nem conjuntos de resultados de consulta para JSON. O interesse de busca por «SQL to JSON» se divide mais ou menos pela metade entre essas duas necessidades; se você chegou aqui esperando a conversão de linha para objeto, vai querer uma ferramenta diferente. O caminho da conversão de esquema é o caso voltado ao desenvolvedor: você tem uma definição de tabela e quer uma descrição estruturada do seu formato que outra ferramenta possa consumir.

Uma breve história do SQL

O SQL foi projetado no San Jose Research Laboratory da IBM no início da década de 1970 por Donald D. Chamberlin e Raymond F. Boyce. O nome original era SEQUEL: Structured English Query Language, concebido como uma interface de mais alto nível para o System R, o banco de dados relacional experimental da IBM. O próprio modelo relacional havia sido publicado em 1970 por Edgar F. Codd; a contribuição de Chamberlin e Boyce foi uma sintaxe que analistas comuns conseguiam ler, modelada em cláusulas em inglês natural (SELECT … FROM … WHERE …) em vez de nos símbolos algébricos de Codd. Boyce (que também emprestaria seu nome à Forma Normal de Boyce-Codd) morreu em 1974, aos 26 anos, antes de a linguagem que ele coinventou ter um lançamento comercial. O nome foi mudado para SQL em 1975 por causa de um conflito de marca registrada com a marca SEQUEL da Hawker Siddeley, embora a pronúncia original «sequel» persista nos Estados Unidos ao lado da internacional «ess-cue-ell».

A ANSI padronizou o SQL em 1986 (SQL-86), a ISO ratificou uma versão essencialmente idêntica em 1987 como ISO/IEC 9075, e o padrão tem sido revisado a cada três a cinco anos desde então: SQL-92 (ainda a base que a maioria dos tutoriais pressupõe), SQL:1999 (consultas recursivas, gatilhos), SQL:2003 (tipo XML, MERGE), SQL:2011 (tabelas temporais), SQL:2016 (suporte a JSON) e, mais recentemente, SQL:2023 (arrays multidimensionais, consultas de grafo de propriedades). Apesar das ondas de tecnologias concorrentes (bancos de dados de objetos na década de 1990, NoSQL no final dos anos 2000, data lakes na década de 2010), o SQL persistiu como a linguagem de consulta dominante para dados estruturados por mais de cinquenta anos. Em 2024, até a maioria das plataformas NoSQL reintroduziu camadas SQL ou parecidas com SQL (o CQL da Cassandra, o estágio de agregação $sql do MongoDB, o PartiQL do DynamoDB, Spark SQL, Trino, DuckDB, BigQuery, Snowflake), confirmando a previsão de Mike Stonebraker de que a linguagem sobreviveria a qualquer motor de armazenamento individual.

O JSON em um parágrafo

O JSON (JavaScript Object Notation) foi especificado por Douglas Crockford em 2001, derivado de um subconjunto da sintaxe de objeto literal do JavaScript, e padronizado como ECMA-404 em 2013 e IETF RFC 8259 em 2017. Ele tem apenas seis tipos de valor (string, número, booleano, null, array, objeto) e nenhum conceito nativo de datas, decimais, binários ou esquemas. O JSON Schema (uma especificação separada, atualmente na versão draft 2020-12) adiciona validação estrutural e de tipo por cima. O valor do JSON Schema para este conversor: é um formato portátil e agnóstico a esquemas que quase todo gerador de código e biblioteca de validação modernos entendem.

A conversão mecânica

Uma entrada representativa:

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

Mapeia para:

{
  "$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 a passo: tokenizar a entrada, localizar CREATE TABLE e o nome da tabela, encontrar a lista de colunas entre parênteses, dividir as definições de coluna nas vírgulas de nível superior (respeitando os parênteses aninhados para coisas como DECIMAL(10,2) ou CHECK (x > 0)), analisar cada coluna em nome + tipo + modificadores, e mapear o tipo SQL para o tipo de JSON Schema mais próximo. NOT NULL vira a inclusão no array required. DEFAULT vira um valor default. PRIMARY KEY geralmente vira uma anotação ou a inclusão em required. CHECK, FOREIGN KEY, UNIQUE e os índices normalmente viram anotações de texto porque o JSON Schema não tem equivalente direto.

O problema dos dialetos

O SQL é notoriamente uma família de dialetos, não uma única linguagem. Até a forma básica de delimitar identificadores difere:

Os nomes de tipo também divergem. INT(11) no MySQL é uma dica de largura de exibição que o PostgreSQL rejeita. SERIAL no PostgreSQL é uma abreviação de INT NOT NULL AUTO_INCREMENT PRIMARY KEY; IDENTITY cumpre o mesmo papel no SQL Server; o SQLite usa AUTOINCREMENT. BOOLEAN é TINYINT(1) por baixo dos panos no MySQL. Os tipos geográficos (GEOMETRY, POINT), os tipos de coluna JSON (JSON, JSONB), os tipos de array (o INTEGER[] do PostgreSQL) e os tipos de vetor de texto completo (VECTOR(1536) no pgvector) não têm equivalente em JSON Schema e acabam como anotações de string opacas. Os dados binários BLOB e BYTEA não têm representação nativa em JSON; a prática padrão é a transformação em string base64 com uma dica contentEncoding.

Tipos SQL vs. tipos JSON, a incompatibilidade de impedância

O SQL tem um sistema de tipos rico; o JSON tem seis tipos de valor e nenhum esquema. Vale saber:

Quando você recorreria a isto

Alternativas modernas

Mais perguntas

E se o meu CREATE TABLE tiver restrições de FOREIGN KEY?

O JSON Schema não tem um conceito nativo de chave estrangeira. A representação mais limpa é uma anotação personalizada (por exemplo, uma propriedade não padrão x-foreign-key) anotando a tabela e a coluna referenciadas. Este conversor preserva a relação como uma nota de texto na saída; se você precisa de uma modelagem de referências totalmente formal, o $ref do JSON Schema mais um bloco de definições separado é o que mais se aproxima, mas é desajeitado para casos de muitos-para-muitos. Para uma modelagem relacional mais rica, considere o DBML ou o Atlas HCL.

Por que a saída não inclui as restrições CHECK?

O JSON Schema consegue expressar muitas restrições CHECK simples: CHECK (age >= 0) vira {"minimum": 0}, CHECK (status IN ('a','b')) vira {"enum": ["a","b"]}; mas as expressões SQL arbitrárias nas cláusulas CHECK (chamadas de função, joins, subconsultas) não têm equivalente em JSON Schema. O conversor reconhece os casos simples e preserva as restrições complexas como anotações de texto em vez de descartá-las silenciosamente.

Posso converter linhas de INSERT para JSON?

Não com esta ferramenta: ela só lida com a conversão em nível de esquema (CREATE TABLE). Para a conversão em nível de linha, a abordagem certa geralmente é nativa do banco de dados: o SELECT row_to_json(t) FROM tbl t do PostgreSQL, o JSON_OBJECT() do MySQL, ou exportar para CSV e usar uma ferramenta de CSV para JSON. O mysqldump --xml canalizado por um conversor de XML para JSON é outro caminho bem trilhado.

Por que o BIGINT é um problema no JSON?

O JSON.parse do JavaScript usa os doubles IEEE 754, que só conseguem representar inteiros até 2^53 = 9.007.199.254.740.992 com exatidão. Números acima disso perdem precisão. O BIGINT do SQL vai até 2^63 ≈ 9,2 quintilhões, muito além da faixa segura de inteiros do JSON. A convenção multiplataforma para transportar o BIGINT pelo JSON com segurança é serializá-lo como string e analisá-lo com BigInt no destino; muitas APIs (os IDs de tweets do Twitter / X, os IDs do Stripe, o bigserial do PostgreSQL) fazem exatamente isso.

Algo é enviado a um servidor?

Não. O analisador roda no seu navegador; a saída JSON é construída localmente. O SQL colado nunca sai do seu dispositivo, o que importa se as suas instruções CREATE TABLE contêm nomes de coluna proprietários, convenções internas de tabela ou outros detalhes que você não quer que sejam registrados. A página funciona offline depois de carregada.

Ferramentas relacionadas

Formatador JSON

Formate, minifique e valide JSON instantaneamente.

Formatador SQL

Formate e embeleze consultas SQL.

Formatador XML

Formate e valide documentos XML.