Convertir JSON a SQL

La salida es una tirada de sentencias INSERT y nada más. Es un límite decidido, no una función que falte. Un JSON te dice que un valor es un número; no te dice si la columna es entera o decimal con dos posiciones, si admite nulos, cuál es la clave primaria, cuáles son las ajenas ni cuánto puede medir un texto. Esas son justamente las decisiones que existe un esquema para registrar.

Un conversor que las adivinara produciría un CREATE TABLE que habría que leer línea por línea antes de fiarse, y eso es más trabajo que escribirlo. En la práctica el ciclo es corto: conviertes una vez, lees la lista de columnas en la primera sentencia, escribes la definición de la tabla a juego y ejecutas. Dos minutos, y las decisiones de esquema quedan donde tienen que estar, en una migración que alguien puede revisar.

No hay ningún otro sitio de donde sacarlo: un documento JSON no tiene nombre para sí mismo, así que lo pone el archivo que sueltas. De pedidos.json sale INSERT INTO pedidos. Todo carácter que un identificador SQL sin comillas no admite se sustituye por un guion bajo, y si el nombre empieza por un dígito se le antepone otro guion bajo.

La consecuencia práctica es que renombrar el archivo antes de convertir es la forma más barata de controlar la salida. Hacerlo después significa buscar y reemplazar en todas las sentencias del archivo, con el cuidado de no tocar un valor que contenga la misma palabra. Treinta segundos en el explorador de archivos ganan a una expresión regular sobre cien mil líneas.

Esta es la sorpresa que se llevan quienes trabajan con datos en español y conviene decirla antes que ninguna otra. El saneado de identificadores admite letras de la A a la Z sin acentos, dígitos y el guion bajo; todo lo demás pasa a guion bajo. Una clave llamada «año» se convierte en la columna a_o, «nº_pedido» en n__pedido y «dirección» en direcci_n.

Y afecta también al nombre de la tabla: informe-año-2024.json produce INSERT INTO informe_a_o_2024. No hay pérdida de datos —los valores viajan intactos— pero sí una lista de columnas que no vas a querer en producción. Si el JSON es tuyo, renombrar las claves en el origen es la solución limpia; si viene de una API ajena, conviene renombrar las columnas en la definición de la tabla y no en las sentencias, y hacer coincidir el orden.

Una tabla relacional es plana y el JSON no lo es, así que un objeto anidado se aplana dentro del nombre de la columna: un registro con un objeto de cliente que contiene una ciudad produce una columna cliente_ciudad. La ruta completa se conserva, el punto que separaba los niveles se vuelve guion bajo porque un punto no es legal en un identificador, y no se descarta ningún valor.

Un nivel de anidamiento produce una tabla que cualquiera declararía sin quejarse. Dos suele seguir siendo razonable. A partir de ahí, la lista de columnas generada es más una señal que un resultado: una estructura JSON de cuatro niveles está describiendo relaciones, y el esquema que le corresponde son varias tablas con claves entre ellas. Cargarla en una sola tabla ancha funciona y vuelve más difícil cada consulta posterior.

Un registro con tres etiquetas produce etiquetas_0, etiquetas_1 y etiquetas_2. Se conserva cada valor y la forma es incorrecta de una manera que empeora: el siguiente registro con cinco etiquetas ensancha la tabla en dos columnas más, y no existe ninguna consulta razonable sobre «la segunda etiqueta».

La respuesta relacional de siempre es una segunda tabla: una fila por etiqueta, con el identificador del padre al lado. Llegar hasta ahí desde una exportación JSON significa convertir dos veces con el array extraído en medio, o cargar la tabla ancha como paso intermedio y normalizar con una consulta. Si tu base de datos tiene un tipo de columna JSON nativo, guardar el array entero en una columna es la tercera opción, y es la buena cuando el array se transporta en lugar de consultarse.

Los registros de una exportación JSON no están obligados a coincidir: una API omite los campos sin valor, así que mil registros pueden presentar una docena de conjuntos de claves distintos. La conversión los reconcilia recogiendo la unión de todas las claves del archivo y escribiendo NULL donde un registro no tiene nada.

Esa uniformidad es lo que hace que el archivo se pueda ejecutar de una tirada: la lista de columnas es idéntica en todas las sentencias, así que una tabla que acepta la primera fila las acepta todas. También explica una diferencia que la gente nota: convertir diez registros de prueba puede dar menos columnas que convertir el archivo entero, porque la muestra no contenía los campos raros. Escribe la definición de la tabla a partir de una conversión completa, nunca de una muestra.

Los números van desnudos, los booleanos como TRUE y FALSE, un nulo del JSON como NULL, y todo lo demás como cadena entre comillas simples con las comillas internas duplicadas. Duplicar es la forma estándar y la que entiende cualquier motor, así que un apellido como O’Donnell o un topónimo como L’Hospitalet se cargan bien en todas partes.

Las barras invertidas se escriben tal cual, sin escapar, que es lo correcto según el estándar y no es como MySQL lee una cadena por defecto: allí una barra invertida inicia una secuencia de escape salvo que esté activo NO_BACKSLASH_ESCAPES. Datos con rutas de Windows, expresiones regulares o LaTeX se cargarán distinto en MySQL que en PostgreSQL. Si tu exportación es de ese tipo, ajusta el modo de la sesión antes de ejecutar el archivo y comprueba una fila afectada en lugar de darlo por hecho.

Aquí un origen JSON es mejor que uno delimitado. Un código de producto «007» es una cadena en el JSON, así que se escribe como cadena SQL entre comillas y llega a la base de datos con sus ceros delante. Un CSV de los mismos datos no tiene tipos, y cada herramienta de la cadena tiene ocasión de decidir que 007 es el número siete. Lo mismo vale para un NIF con letra o un código postal que empieza por cero.

La protección alcanza también a los identificadores numéricos largos exportados como cadena. Cuando se exportaron como número JSON, en cambio, se aplica el techo de la coma flotante: cualquier cosa por encima de dieciséis dígitos ya perdió precisión antes de que esta conversión la viera, y ningún cuidado en la escritura la recupera. Si la exportación está en tu mano, exportar identificadores como cadena es el arreglo, y es un arreglo en el origen y no aquí.

La salida es una sentencia por registro, sin envoltura de transacción y sin cláusula VALUES de varias filas. Ejecutar cincuenta mil sentencias sueltas desde un cliente es lento porque cada una es una ida y vuelta. Envolver el archivo entero entre BEGIN y COMMIT es una línea a cada extremo y suele ser la mayor mejora disponible de una sola vez.

Las sentencias son deliberadamente planas y portables: sin comillas propias de ningún motor, sin cláusula de conflicto y sin prefijo de esquema. Añadir lo que quiera tu motor es un reemplazo sobre INSERT INTO —el nombre del esquema, un ON CONFLICT DO NOTHING para que la carga se pueda repetir— y partir de la forma más simple posible es lo que hace esas ediciones predecibles.

Para un archivo de datos iniciales, un juego de pruebas o unos pocos miles de filas, las sentencias son la forma cómoda: se leen, se pueden guardar en el repositorio y se ejecutan en cualquier sitio donde un cliente sepa conectarse. Ese es el trabajo para el que está escrita esta página.

Pasado cierto tamaño la aritmética cambia. Todos los motores tienen una vía masiva —COPY en PostgreSQL, LOAD DATA en MySQL, la importación de una herramienta cliente— que lee un archivo delimitado mucho más rápido de lo que ejecuta inserciones una a una, y en un millón de filas la diferencia es de minutos frente a horas. En ese caso convierte la misma exportación a CSV o TSV, o a NDJSON si el destino es un almacén analítico en lugar de una base relacional.

Las sentencias las genera JavaScript en esta misma pestaña. No se sube nada, no hay cuenta ni cola, y el límite es de 100 MB por archivo, con la memoria del equipo como techo real, porque el documento entero se analiza antes de escribir la primera línea.

En esta pareja concreta eso no es un extra. Lo que está a punto de insertarse en una base de datos es, por definición, información que alguien ha decidido conservar: clientes, pedidos, movimientos, cuentas. Pasarla por un conversor ajeno para que le duplique unas comillas sería un intercambio muy malo, y aquí no hay ningún intercambio que hacer.