Conversor gratuito de SQL a JSON

Acerca de la conversión SQL → JSON

Esta herramienta analiza las instrucciones SQL CREATE TABLE y las convierte al formato de esquema JSON. Extrae los nombres de columna, los tipos de datos (INT, VARCHAR, TEXT, BOOLEAN, DATE, TIMESTAMP, DECIMAL) y las restricciones (NOT NULL, PRIMARY KEY, valores DEFAULT). La salida JSON es adecuada para la documentación de API, el diseño de bases de datos o las herramientas de migración.

Tipos de datos SQL admitidos

• INT / INTEGER · valores enteros de 32 bits
• VARCHAR(n) · texto de longitud variable con longitud máxima
• TEXT · texto de longitud ilimitada
• BOOLEAN / BOOL · valores verdadero/falso
• DATE · fechas calendario sin hora
• TIMESTAMP · fecha y hora con soporte de zona horaria
• DECIMAL(p,s) · números decimales precisos

Preguntas frecuentes

¿Qué dialectos SQL se admiten?

Este convertidor gestiona la sintaxis SQL estándar usada por MySQL, PostgreSQL, SQL Server y SQLite. Las funcionalidades específicas de un dialecto pueden no reconocerse por completo.

¿Gestiona restricciones complejas?

El convertidor reconoce NOT NULL, PRIMARY KEY, DEFAULT y la información de tipo básica. Las restricciones complejas como CHECK o FOREIGN KEY se guardan como anotaciones de texto.

¿Puedo usar la salida JSON directamente?

¡Sí! La salida JSON está formateada para la legibilidad y se puede usar en esquemas de API, interfaces TypeScript o generadores de documentación.

Esquema, no datos: qué hace esta herramienta

Este conversor toma una sentencia SQL CREATE TABLE y emite un JSON Schema: una descripción de las columnas, los tipos y las restricciones básicas, adecuada para contratos de API, la generación de tipos de TypeScript y las migraciones a almacenes de documentos. No convierte filas INSERT ni conjuntos de resultados de consultas a JSON. El interés de búsqueda en «SQL a JSON» se reparte más o menos por la mitad entre esas dos necesidades; si has llegado esperando una conversión de filas a objetos, querrás una herramienta diferente. La vía de conversión de esquemas es el caso orientado a los desarrolladores: tienes una definición de tabla y quieres una descripción estructurada de su forma que otra herramienta pueda consumir.

Una breve historia de SQL

SQL se diseñó en el Laboratorio de Investigación de San José de IBM a principios de la década de 1970, a cargo de Donald D. Chamberlin y Raymond F. Boyce. El nombre original era SEQUEL: Structured English Query Language, concebido como una interfaz de más alto nivel para System R, la base de datos relacional experimental de IBM. El propio modelo relacional lo había publicado en 1970 Edgar F. Codd; la contribución de Chamberlin y Boyce fue una sintaxis que los analistas corrientes pudieran leer, inspirada en cláusulas del inglés natural (SELECT … FROM … WHERE …) en lugar de en los símbolos algebraicos de Codd. Boyce (que también daría su nombre a la forma normal de Boyce-Codd) murió en 1974 a los 26 años, antes de que el lenguaje que cocreó llegara al mercado comercial. El nombre se cambió a SQL en 1975 debido a un conflicto de marca registrada con la marca SEQUEL de Hawker Siddeley, aunque la pronunciación original «sequel» persiste en Estados Unidos junto con la internacional «ess-cue-ell».

ANSI estandarizó SQL en 1986 (SQL-86), ISO ratificó una versión esencialmente idéntica en 1987 como ISO/IEC 9075, y el estándar se ha revisado cada tres a cinco años desde entonces: SQL-92 (todavía la base que asumen la mayoría de los tutoriales), SQL:1999 (consultas recursivas, disparadores), SQL:2003 (tipo XML, MERGE), SQL:2011 (tablas temporales), SQL:2016 (compatibilidad con JSON) y, más recientemente, SQL:2023 (matrices multidimensionales, consultas de grafos de propiedades). A pesar de las oleadas de tecnologías competidoras (las bases de datos de objetos en los años noventa, NoSQL a finales de la década de 2000, los lagos de datos en la de 2010), SQL ha persistido como el lenguaje de consulta dominante para los datos estructurados durante más de cincuenta años. Para 2024, incluso la mayoría de las plataformas NoSQL han reintroducido SQL o capas similares a SQL (el CQL de Cassandra, la etapa de agregación $sql de MongoDB, PartiQL de DynamoDB, Spark SQL, Trino, DuckDB, BigQuery, Snowflake), lo que confirma la predicción de Mike Stonebraker de que el lenguaje sobreviviría a cualquier motor de almacenamiento concreto.

JSON en un párrafo

JSON (JavaScript Object Notation) lo especificó Douglas Crockford en 2001, derivado de un subconjunto de la sintaxis de literales de objeto de JavaScript, y se estandarizó como ECMA-404 en 2013 e IETF RFC 8259 en 2017. Solo tiene seis tipos de valor (cadena, número, booleano, null, array, objeto) y ningún concepto nativo de fechas, decimales, binarios ni esquemas. JSON Schema (una especificación aparte, actualmente en el borrador 2020-12) añade encima la validación estructural y de tipos. El valor de JSON Schema para este conversor: es un formato portátil y agnóstico respecto al esquema que casi todos los generadores de código y bibliotecas de validación modernos entienden.

La conversión mecánica

Una 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
);

Se corresponde con:

{
  "$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"]
}

Paso a paso: tokenizar la entrada, localizar CREATE TABLE y el nombre de la tabla, encontrar la lista de columnas entre paréntesis, dividir las definiciones de columna por las comas de nivel superior (respetando los paréntesis anidados para cosas como DECIMAL(10,2) o CHECK (x > 0)), analizar cada columna en nombre + tipo + modificadores, y asignar el tipo SQL al tipo de JSON Schema más cercano. NOT NULL se convierte en pertenencia al array required. DEFAULT se convierte en un valor default. PRIMARY KEY suele convertirse en una anotación o en pertenencia a required. CHECK, FOREIGN KEY, UNIQUE y los índices normalmente se convierten en anotaciones de texto porque JSON Schema no tiene un equivalente directo.

El problema de los dialectos

SQL es, célebremente, una familia de dialectos, no un único lenguaje. Incluso el entrecomillado básico de identificadores difiere:

• MySQL / MariaDB: comillas invertidas: `column_name`.
• PostgreSQL y el estándar SQL, comillas dobles: "column_name".
• SQL Server / MS Access: corchetes: [column_name].
• SQLite: permisivo, acepta los tres.

Los nombres de tipo también divergen. INT(11) en MySQL es una indicación de anchura de visualización que PostgreSQL rechaza. SERIAL en PostgreSQL es una forma abreviada de INT NOT NULL AUTO_INCREMENT PRIMARY KEY; IDENTITY cumple el mismo papel en SQL Server; SQLite usa AUTOINCREMENT. BOOLEAN es TINYINT(1) internamente en MySQL. Los tipos geográficos (GEOMETRY, POINT), los tipos de columna JSON (JSON, JSONB), los tipos de matriz (el INTEGER[] de PostgreSQL) y los tipos de vector de texto completo (VECTOR(1536) en pgvector) no tienen equivalente en JSON Schema y acaban como anotaciones de cadena opacas. Los datos binarios BLOB y BYTEA no tienen representación nativa en JSON; la práctica estándar es convertirlos a cadena en base64 con una indicación contentEncoding.

Tipos de SQL frente a tipos de JSON: el desajuste de impedancia

SQL tiene un sistema de tipos rico; JSON tiene seis tipos de valor y ningún esquema. Conviene saber:

• Tipos numéricos: INT, BIGINT, SMALLINT y TINYINT colapsan todos al number de JSON. JavaScript y la mayoría de los analizadores de JSON usan el punto flotante de doble precisión IEEE 754, que solo representa con exactitud los enteros hasta 2^53. Los valores BIGINT por encima de eso pierden precisión al pasar por los analizadores de JSON en un ciclo de ida y vuelta. Algunas canalizaciones serializan BIGINT como una cadena entrecomillada para preservar la precisión; ese es un patrón de diseño conocido de las API de JSON.
• Decimal / numérico: DECIMAL(10,2) para el dinero es un tipo de precisión exacta en SQL, pero se convierte en un número JSON de punto flotante con pérdidas a menos que se serialice como una cadena. Las API financieras casi siempre serializan el dinero como cadenas decimales ("19.99") por esta razón.
• Fecha / hora / marca de tiempo: JSON no tiene un tipo temporal nativo. La convención estándar son las cadenas ISO 8601 ("2026-05-02T14:30:00Z"), con la anotación { "type": "string", "format": "date-time" } de JSON Schema. TIMESTAMP WITH TIME ZONE en PostgreSQL preserva la información de zona; TIMESTAMP WITHOUT TIME ZONE no lo hace: al ir y volver por JSON normalmente se aplana la distinción.
• Booleanos: correspondencia directa true / false. El BIT de SQL Server a menudo llega como 1/0; este conversor lo normaliza a true/false.
• NULL: el null de JSON. Conviene señalar que la ausencia de una clave ({}) es semánticamente distinta de un null explícito ({"x": null}) en la mayoría de los consumidores de JSON.
• Enumeraciones: el ENUM('a','b','c') de SQL se corresponde limpiamente con el {"enum": ["a","b","c"]} de JSON Schema.

Cuándo recurrirías a esto

• Generar esquemas de OpenAPI / Swagger a partir de tablas de base de datos existentes para una API que devuelve la misma forma.
• Generar tipos iniciales de TypeScript / Zod / io-ts: una vez que tienes el JSON Schema, herramientas como quicktype o json-schema-to-typescript producen definiciones de tipos automáticamente.
• Migrar de SQL → MongoDB / Firestore / DynamoDB: el primer artefacto que sueles querer es una lista de formas de documento; JSON Schema es un formato intermedio limpio para ese ejercicio de planificación.
• Simulación para el frontend: los ingenieros de frontend que desarrollan contra un backend que aún no existe necesitan una descripción JSON de la forma de la fila para poder generar datos falsos con faker.js, MSW o json-server.
• Documentación interna de diccionario de datos: los documentos de modelos de DBT, las wikis de diseño y los repositorios de esquema como código consumen todos descripciones JSON de las formas de las tablas.
• Generación de fixtures de prueba: las bibliotecas de pruebas basadas en propiedades (hypothesis, fast-check) y las bibliotecas de factorías necesitan una descripción de la forma esperada para generar datos de prueba que la satisfagan.

Alternativas modernas

• Salida JSON nativa de la base de datos. PostgreSQL tiene row_to_json(), json_agg() y la familia jsonb_; MySQL tiene JSON_OBJECT() y JSON_ARRAYAGG(); SQL Server tiene FOR JSON. Si controlas la base de datos, normalmente puedes saltarte un conversor por completo y emitir JSON directamente desde la consulta.
• Introspección del ORM. Prisma, Drizzle, SQLAlchemy, TypeORM, Sequelize-auto y bibliotecas similares pueden examinar las tablas existentes y emitir definiciones de tipos o archivos de esquema en sus propios formatos, a menudo más cercanos a lo que realmente quieres que un JSON Schema en bruto.
• Herramientas de esquema como código. Atlas (HCL), Liquibase (YAML), Sqitch (SQL) y DBML (Database Markup Language) describen las formas de las tablas en sus propios DSL, que tienen vocabularios de restricciones más ricos que JSON Schema.

Más preguntas

¿Y si mi CREATE TABLE tiene restricciones FOREIGN KEY?

JSON Schema no tiene un concepto nativo de clave foránea. La representación más limpia es una anotación personalizada (por ejemplo, una propiedad no estándar x-foreign-key) que indique la tabla y la columna referenciadas. Este conversor preserva la relación como una nota de texto en la salida; si necesitas un modelado de referencias totalmente formal, lo que más se aproxima es $ref de JSON Schema más un bloque de definiciones aparte, pero resulta engorroso para los casos de muchos a muchos. Para un modelado relacional más rico, considera DBML o Atlas HCL.

¿Por qué la salida no incluye las restricciones CHECK?

JSON Schema puede expresar muchas restricciones CHECK simples: CHECK (age >= 0) se convierte en {"minimum": 0}, CHECK (status IN ('a','b')) se convierte en {"enum": ["a","b"]}; pero las expresiones SQL arbitrarias en las cláusulas CHECK (llamadas a funciones, uniones, subconsultas) no tienen equivalente en JSON Schema. El conversor reconoce los casos simples y preserva las restricciones complejas como anotaciones de texto en lugar de descartarlas en silencio.

¿Puedo convertir filas INSERT a JSON?

Con esta herramienta no: solo gestiona la conversión a nivel de esquema (CREATE TABLE). Para la conversión a nivel de fila, el enfoque correcto suele ser nativo de la base de datos: el SELECT row_to_json(t) FROM tbl t de PostgreSQL, el JSON_OBJECT() de MySQL, o exportar a CSV y usar una herramienta de CSV a JSON. mysqldump --xml redirigido a través de un conversor de XML a JSON es otro camino muy transitado.

¿Por qué BIGINT es un problema en JSON?

El JSON.parse de JavaScript usa dobles IEEE 754, que solo pueden representar con exactitud enteros hasta 2^53 = 9.007.199.254.740.992. Los números por encima de eso pierden precisión. El BIGINT de SQL llega hasta 2^63 ≈ 9,2 trillones, muy por encima del rango seguro de enteros de JSON. La convención multiplataforma para transportar BIGINT de forma segura a través de JSON es serializarlo como una cadena y analizarlo con BigInt en el destino; muchas API (los identificadores de tuit de Twitter / X, los identificadores de Stripe, el bigserial de PostgreSQL) hacen exactamente esto.

¿Se envía algo a un servidor?

No. El analizador se ejecuta en tu navegador; la salida JSON se construye localmente. El SQL pegado nunca sale de tu dispositivo, lo cual importa si tus sentencias CREATE TABLE contienen nombres de columna propietarios, convenciones de tablas internas u otros detalles que no quieres que se registren. La página funciona sin conexión una vez cargada.

Herramientas relacionadas