YamlBox

Generadores de código · 5 minutos de lectura

JSON a SQL: de una carga útil a una tabla que puedes consultar

A veces, la ruta más rápida desde un archivo JSON a una consulta SQL es crear una tabla a partir de él. La conversión de JSON a SQL produce el esquema y las filas en un solo paso, lo cual es ideal para elementos fijos, análisis de scratch y siembra de una base de datos local, siempre que lo mantenga fuera de su historial de migración.

Actualizado

Cómo se asignan los tipos de JSON a SQL

  • Cadenas → `TEXT` (`VARCHAR(n)` cuando conoces el presupuesto de longitud).
  • Números enteros → `INTEGER` / `BIGINT`, decimales → `NUMERIC` en lugar de punto flotante, especialmente para el dinero.
  • Booleanos → `BOOLEAN`.
  • Objetos y matrices anidados → `JSONB` en PostgreSQL, `JSON` en MySQL 8, o normalícelos en tablas secundarias cuando los datos lleguen para quedarse.
  • Claves faltantes → columnas que aceptan valores NULL, nunca un valor predeterminado que falsifique un valor.

Una tabla generada es un excelente punto de partida y una migración terrible. Escriba el esquema que desee y luego utilice el SQL generado como referencia para los nombres y tipos de columnas.

Escapar no es opcional

Las cadenas en JSON contienen habitualmente apóstrofes (`O’Brien`, `it's done`) y, al pegarlas en SQL a mano, terminan el literal de cadena antes de tiempo y rompen la declaración. Las declaraciones INSERT generadas duplican cada cotización correctamente, que es lo más útil que la conversión hace por usted. Para inserciones masivas, ajuste las filas en una declaración para que la base de datos pueda realizar la escritura por lotes en lugar de confirmarla por línea.

Buenos usos, malos usos

Los datos de los dispositivos para las pruebas, una copia local de una exportación API, la creación de un entorno de demostración y la respuesta a una pregunta única en SQL se benefician de una conversión de JSON a SQL. La gestión del esquema de producción no: las migraciones necesitan revisión, índices, restricciones y una ruta de reversión. Genere la tabla y luego escriba a mano la migración que se envía.

Matrices y objetos: ¿aplanar o almacenar?

Si una matriz es una lista fija de escalares, una tabla secundaria con una clave externa simplifica las consultas. Si se trata de una carga útil genuinamente dinámica (cuerpos de webhooks, metadatos de terceros), almacenarla como `JSONB` e indexar las rutas que consulta es la opción pragmática. Decide cómo lo consultarás: cualquier cosa que filtres o a la que te unas pertenece a una columna.

Ejecútelo en el navegador.

Las exportaciones de bases de datos y los volcados API son exactamente las cargas útiles que no deben cargarse en un servicio desconocido. La conversión de JSON a SQL aquí ocurre completamente en la página, por lo que la declaración que copia se crea a partir de datos que nunca salieron de su máquina y la herramienta aún funciona sin conexión.

JSON a SQL — preguntas frecuentes

¿Qué dialecto SQL debo generar?

Apunte a la base de datos en la que realmente lo ejecutará: PostgreSQL para `JSONB`, MySQL 8 para `JSON` e identificadores con comillas invertidas, SQLite para trabajo local liviano. Las reglas de citación y los nombres de tipos difieren entre ellos, por lo que la regeneración por dialecto es mejor que la adaptación manual.

¿Puedo insertar JSON matrices en una sola columna SQL?

Sí, en bases de datos con un tipo de columna JSON: la matriz se convierte en `JSONB` o `JSON` y se consulta con operadores de ruta. Si necesita unir o agregar elementos, una tabla secundaria es el mejor modelo.

¿El SQL generado es seguro mediante inyección?

Las declaraciones generadas son para que usted las ejecute donde elija, y los valores de cadena se escapan como literales. No sustituyen las consultas parametrizadas en el código de la aplicación; nunca cree consultas mediante concatenación en un servidor.

Herramientas mencionadas en esta publicación.

Explore la lista completa de 19 herramientas

Más artículos para leer

Todas las 19 publicaciones →