Convertir NDJSON a SQL

La correspondencia es tan directa como suena. Cada línea no vacía del origen produce una sentencia INSERT, así que la salida tiene tantas sentencias como registros tenía la entrada y contar líneas en cualquiera de los dos archivos da el mismo número. No hay cabecera de la que descontar y nada dentro de los datos puede introducir un salto de línea, porque dentro del JSON va escapado.

Esa previsibilidad es lo que hace cómodo este par. Si una carga informa de 412.000 filas insertadas y el archivo tenía 412.000 líneas, la carga está completa: sin reconciliar nada, sin la duda de la fila parcial y sin preguntarse si un campo entrecomillado se ha tragado un salto de registro, que es lo que pasa con un archivo delimitado.

Un archivo de eventos es, casi siempre, datos personales. Lleva direcciones IP, identificadores de sesión, rutas solicitadas, a veces un correo electrónico dentro de un mensaje de error y de vez en cuando un token en una cadena de consulta. Subirlo a un conversor cualquiera no es una comodidad: es una comunicación de datos a un tercero del que no sabes ni dónde está alojado.

Bajo el Reglamento General de Protección de Datos eso exige una base jurídica, un encargado de tratamiento con contrato y una valoración de las transferencias fuera del Espacio Económico Europeo, y ninguna de esas tres cosas existe cuando alguien arrastra un fichero a la primera web que le sale en el buscador. Aquí las sentencias se generan en tu pestaña y el archivo no viaja, con lo cual el problema no se gestiona: no llega a plantearse.

Añade a lo anterior una circunstancia agravante que conoce cualquiera que haya estado de guardia: el motivo para convertir un registro a SQL suele ser una incidencia. Algo ha fallado, hay que cruzar los eventos de una hora concreta con la tabla de clientes y hace falta hacerlo ahora, no mañana.

Es exactamente el instante en que se toman las peores decisiones sobre dónde poner un archivo. Que la herramienta funcione sin subir nada, sin cuenta y sin cola no es una postura ideológica en ese contexto; es lo que evita que una incidencia técnica de una tarde acabe convertida en una notificación a la autoridad de control por una brecha de datos.

Este es el punto donde un formato de origen pensado para leerse en flujo no te regala una conversión en flujo. La lista de columnas tiene que ser idéntica en todas las sentencias y se construye con la unión de las claves de todas las líneas, así que un campo que aparezca únicamente en el último registro sigue convirtiéndose en columna y no se puede escribir nada hasta haberlo visto.

La consecuencia es un techo de memoria más que un límite de tamaño: el archivo entero vive en la pestaña mientras se convierte. Decenas de megabytes no son nada, varios cientos ya hacen sudar al navegador, y a partir de ahí la respuesta es partir el archivo. NDJSON se parte sin riesgo en cualquier salto de línea, así que un «split» por número de líneas produce ficheros válidos que se convierten y se cargan por separado.

Un flujo que escupe peticiones, errores y finalizaciones de tarea en el mismo archivo tiene dentro tres conjuntos de claves distintos. La reconciliación lo resuelve sin descartar nada: cada clave se convierte en columna y la línea que no la traiga aporta NULL. La tabla que acabas declarando es la unión de tres esquemas.

Para una tarde de análisis eso suele ser aceptable. Para algo que vaya a durar, filtrar el archivo por tipo de evento y cargar tres tablas produce un esquema que se puede indexar con criterio y consultas que no empiezan todas filtrando por una columna discriminante. Separar antes es una expresión de jq por tipo, y las tablas que salen son las que habrías diseñado a mano.

La salida no lleva definición de esquema, a propósito. El JSON te dice que un valor es un número y no si la columna es entera o decimal con dos posiciones, si admite nulos, cuál es la clave primaria o cuánto puede medir el texto, que es la mayor parte de para lo que sirve un esquema.

El ciclo práctico consiste en convertir, leer la lista de columnas de la primera sentencia, escribir la tabla que encaje y ejecutar. Con archivos grandes hay un aviso que importa más que en otros sitios: deriva las columnas de una conversión del archivo entero y nunca de una muestra. Un campo raro que aparezca en una línea de medio millón sigue apareciendo como columna en todas las sentencias, y una tabla declarada a partir de los primeros mil registros rechazará la carga completa al llegar a ella.

Los registros estructurados anidan —un objeto de petición con método y ruta, un bloque de contexto con un identificador de traza— y una tabla relacional no. La ruta se pliega dentro del nombre de la columna, de modo que cada valor hoja recibe su propia columna y algo como el método de la petición acaba llamándose «request_method».

Uno o dos niveles producen una tabla que declararías sin quejarte, y eso cubre a la mayoría de las bibliotecas de registro. Un registro que arrastre una carga útil serializada entera produce una columna por cada campo de dentro, y ahí la pregunta útil es qué subárbol pretendes consultar realmente. Extraerlo antes de convertir da una tabla más estrecha y un CREATE TABLE mucho más corto.

Los valores se escriben como literales SQL: los números desnudos, los booleanos como TRUE y FALSE, los nulos como NULL y el texto entre comillas simples con las comillas internas dobladas. Doblar es la forma portátil y la leen todos los motores, así que un mensaje con un apóstrofo carga bien en cualquier sitio.

Dos detalles que conviene comprobar en lugar de dar por hechos. Las barras invertidas se escriben tal cual, que es lo correcto según el estándar y no es como MySQL lee una cadena con su configuración por defecto, donde la barra abre una secuencia de escape; un registro está lleno de ellas, entre rutas de Windows, expresiones regulares y JSON escapado dentro de un mensaje. Y TRUE y FALSE no son válidos en todos los dialectos. Prueba una fila afectada antes de lanzar el archivo entero.

La tabla se llama como el archivo sin su extensión, con todo lo que un identificador SQL no admite sustituido por guiones bajos, y con un guion bajo delante si empieza por un dígito. Un archivo llamado «eventos-2026-08.ndjson» produce sentencias contra «eventos_2026_08».

Los identificadores no se entrecomillan en la salida, ni el de la tabla ni los de las columnas. Eso es lo que se quiere en la práctica totalidad de los casos, y significa que renombrar el archivo antes de convertir es infinitamente más rápido que editar medio millón de sentencias después. Vale la pena decidir el nombre de la tabla antes de arrastrar nada.

Las sentencias llegan una por línea y sin ninguna transacción alrededor. Ejecutar eso tal cual contra una base de datos hace que cada sentencia sea su propia transacción, con su confirmación y su ida y vuelta, que es la forma más lenta posible de insertar medio millón de filas.

Dos ediciones cambian la aritmética. Envolver el archivo entre BEGIN y COMMIT es una línea en cada extremo y suele ser la mayor mejora disponible. Quitar los índices antes de cargar y volver a crearlos después es la segunda, y en una tabla con tres índices a menudo vuelve a reducir el tiempo a la mitad. Ninguna de las dos es específica de este conversor, y las dos importan más cuanto más grande sea el archivo.

Hay un tamaño a partir del cual las sentencias son el instrumento equivocado por muy bien agrupadas que estén. Todos los motores tienen una vía de carga masiva —COPY en PostgreSQL, LOAD DATA en MySQL, una importación en el cliente gráfico— que lee un archivo delimitado directamente y se salta el análisis sintáctico de las sentencias, y con un millón de filas la diferencia son minutos frente a horas.

Convertir ese mismo NDJSON a CSV o TSV y usar esa vía es el mejor plan por encima de unas cien mil filas. Las sentencias conservan dos ventajas que hay que pesar: funcionan allí donde un cliente pueda conectarse, incluida una base de datos gestionada en la que no puedes dejar un fichero en el servidor, y se revisan y se guardan en un repositorio como material de pruebas. Por debajo de ese umbral, los INSERT siguen siendo la respuesta correcta.

Si alguna línea no es JSON válido, la conversión falla y el mensaje indica qué línea es. No se produce nada parcial, que es justo el comportamiento que quieres aquí: un archivo de sentencias a medio escribir cargado en una tabla es bastante peor que no tener archivo.

En un registro, una línea malformada suele significar una escritura truncada y no una errata: un proceso muerto a mitad de volcado, un archivo rotado por un cron justo en un límite. Saber cuál es te permite recortar la cola, contar lo que estás descartando y cargar el resto a conciencia, en lugar de descubrir un hueco en los datos tres consultas después. Conviene recordar también que SQL aquí es solo destino: de un archivo de sentencias INSERT no se sale a ningún otro formato.