Convertir CSV a SQL

Conviene decirlo antes que nada, porque para buena parte de quienes buscan esta conversión la respuesta es que no la necesitan. Postgres tiene COPY, MySQL tiene LOAD DATA INFILE, SQLite tiene .import y SQL Server tiene BULK INSERT, y todos leen un archivo delimitado directamente, aplican los tipos de columna una sola vez y escriben por bloques. Por encima de unos pocos miles de filas, ese camino gana con holgura.

Lo que convierte esta página en la respuesta correcta es una restricción, no una preferencia. Los cargadores masivos necesitan que el archivo esté donde el servidor lo alcance, y a menudo necesitan un privilegio que la cuenta no tiene. Si lo único que tienes es una ventana de consultas —una consola de base de datos gestionada, una herramienta de migraciones, un ticket que ejecutará otra persona—, las sentencias son la única moneda disponible.

La salida es un archivo de sentencias INSERT, una por fila de datos, cada una nombrando la tabla y listando las columnas tomadas de la cabecera. No hay nada antes. Es una negativa, no un olvido: un CSV no registra tipos, ni longitudes, ni claves, ni si algo admite nulos, así que un esquema generado sería un conjunto de suposiciones presentado con la autoridad de una definición.

El coste de suponer mal es asimétrico. Una fila mala es un registro malo y se arregla con un DELETE. Un VARCHAR(50) deducido del valor más largo de una muestra trunca direcciones durante dos años antes de que alguien se dé cuenta. Aquí se da por hecho que la tabla la has diseñado tú, y si además necesitas la definición, escríbela a mano y pégala arriba: las sentencias generadas funcionan contra ella sin tocarlas.

Se toma el nombre del CSV sin su extensión. Por el camino se sanea: todo lo que no sea letra, cifra o guion bajo pasa a ser un guion bajo, y un nombre que empiece por cifra recibe uno delante, porque un identificador no puede comenzar con un número. Un archivo llamado «2024 pedidos.csv» produce por tanto inserciones en _2024_pedidos.

El mismo saneado se aplica a los nombres de columna que salen de la cabecera, y esa es la parte que más sorprende. Un encabezado que ponga «Importe total (€)» acaba siendo Importe_total____ y no coincidirá con nada de tu tabla. Los acentos y la eñe corren la misma suerte: «Año» se convierte en A_o. Ajusta la fila de cabecera y renombra el archivo antes de convertir y el resultado no necesita ninguna edición.

Un CSV no tiene tipos: todo son caracteres hasta que algo decide otra cosa. La lectura deduce números, booleanos y valores nulos porque es lo que casi siempre se quiere, y lo que deduzca es lo que ve el escritor de SQL: un valor leído como número se escribe desnudo y uno que sigue siendo texto se escribe entrecomillado.

En España eso golpea justo en la columna que más duele. Los códigos postales de Álava empiezan por 01, los de Barcelona por 08 y los de Madrid por 28; los dos primeros pierden el cero y quedan como 1001 y 8001, sin comillas. Insertados en una columna de texto entran sin protestar y sin rellenar, que es el peor resultado posible porque nada se queja. Lo mismo ocurre con referencias largas de pedido, que se convierten en coma flotante y pierden la última cifra.

Excel en español exporta con punto y coma como separador precisamente para que 1,50 no rompa el archivo, y el separador se detecta solo, con un control para forzarlo cuando la detección no tiene con qué decidir. Hasta ahí, bien. Lo interesante viene después: 1,50 no encaja en el patrón de un número, así que se queda como texto.

El escritor de SQL lo entrecomilla, y esa sentencia entra en una columna de texto y falla contra una columna numérica. Es el reverso exacto del problema del código postal: allí se numeraba lo que era texto y aquí se textualiza lo que era número. La solución es la misma en ambos casos y está en el origen: exporta los importes con punto decimal, o revisa la primera sentencia generada antes de ejecutar nada.

Un campo vacío se convierte en la palabra clave NULL y no en una cadena vacía. Casi siempre es la lectura correcta de un hueco en una exportación, y es además la que una restricción NOT NULL rechazará en voz alta en lugar de aceptar en silencio, que es el comportamiento que interesa.

Donde el hueco significaba de verdad una cadena vacía, el archivo nunca guardó esa distinción y ningún conversor puede recuperarla. Si tu tabla tiene una columna donde el vacío y el nulo significan cosas distintas —un campo libre opcional, sobre todo—, codifica la diferencia en el CSV antes de convertir. Al revés también aplica: donde cada hueco debería tomar un valor por defecto, es mejor omitir la columna del INSERT que insertar NULL encima del defecto.

Los números y los booleanos se escriben desnudos. El texto se envuelve en comillas simples y cualquier apóstrofo interior se duplica, de modo que O’Brien se escribe con dos comillas seguidas en medio. Es la convención ANSI y todos los motores importantes la leen igual.

El escape con barra invertida se ha dejado fuera a conciencia. Es una extensión de MySQL cuyo comportamiento depende de un ajuste del servidor y no de la sentencia, lo que significa que un archivo que la use puede ejecutarse bien en un servidor y corromper datos en otro de la misma versión. Duplicar la comilla funciona en todas partes, y el archivo resultante puede versionarse y reproducirse contra varios entornos sin arrastrar una suposición sobre ninguno.

Un campo que ponga true o false se lee como booleano y se escribe como el literal desnudo TRUE o FALSE. Postgres lo acepta tal cual, MySQL trata esas palabras como alias de 1 y 0, y SQLite las admite desde hace años.

SQL Server no. Su tipo bit quiere 1 y 0, y una sentencia que contenga TRUE no llega a analizarse, cosa que descubrirás en la primera sentencia si tienes suerte y en la cuatrocientas si la columna booleana arranca con una tanda de huecos. Si ese es el destino, haz la sustitución antes de ejecutar nada y comprueba primero que ninguna columna de texto contiene esa palabra suelta.

Nada en esta conversión interpreta una fecha. Un campo que diga 2024-03-11 no es numérico, así que sigue siendo texto y se escribe entrecomillado; uno que diga 11/03/2024 hace lo mismo. Eso es mejor de lo que suena: una fecha ISO entrecomillada entra correctamente en una columna de fecha en todos los motores citados aquí.

También es por donde viaja la ambigüedad sin tocarse. En España 11/03/2024 es el once de marzo; el mismo archivo exportado por un sistema configurado a la americana querría decir el tres de noviembre, y el CSV no lo dice. La base de datos lo interpretará según su propia configuración regional y no avisará de que ha elegido. Si no puedes verificar el origen, carga en una columna de texto intermedia y convierte de forma explícita.

Las sentencias se emiten una a una, sin BEGIN, sin COMMIT y sin agrupar varias filas en un mismo VALUES. Ejecutado tal cual contra un servidor remoto, eso son cincuenta mil viajes de ida y vuelta y cincuenta mil confirmaciones implícitas, lo bastante lento como para notarse y con una tabla a medio cargar si algo falla por el camino.

Dos líneas arreglan ambos problemas: envuelve el archivo en BEGIN y COMMIT y la carga entera se vuelve atómica y bastante más rápida. El archivo también pesa más que los datos que contiene, porque la lista de columnas se repite en cada línea; una tabla ancha con nombres largos puede producir un SQL varias veces mayor que el CSV de partida.

El análisis del archivo y la escritura de las sentencias son JavaScript corriente ejecutándose en esta página, así que no hay subida ni cola; lo que acota el trabajo es el límite gratuito de 100 MB por archivo y después la memoria de tu propio equipo. Se puede comprobar en diez segundos desconectando la red y convirtiendo igual.

Aquí eso pesa más que en otros pares. Lo que va camino de una tabla es normalmente un listado de clientes, un volcado de pedidos, una nómina o un fichero de socios: datos personales en el sentido literal del reglamento. Pegar uno de esos en una web ajena para que lo procese es exactamente la práctica que las políticas internas de tratamiento están escritas para impedir.