Convertir XLSX a SQL

La salida es un fichero con una sentencia INSERT por cada fila de la hoja, indicando la tabla y la lista de columnas tomada de la cabecera. No hay ningún CREATE TABLE al principio, y su ausencia es una decisión, no un olvido.

Una hoja de cálculo no guarda tipos, ni longitudes, ni claves, ni restricciones. Cualquier esquema deducido de ella sería una suposición presentada como certeza, y una suposición equivocada en un esquema es mucho más cara que en una fila: un campo de texto demasiado corto trunca direcciones durante dos años sin que nadie lo note. Si necesitas la tabla, escribe tú el CREATE y ponlo encima; las sentencias generadas funcionan debajo sin tocar nada.

El conversor toma el nombre del libro, le quita la extensión y lo usa en todas las sentencias. Antes lo depura: todo lo que no sea letra, dígito o guion bajo se sustituye por un guion bajo, y si el nombre empieza por una cifra se le antepone otro guion bajo, porque un identificador no puede empezar por número.

De ahí sale el consejo más útil de toda la página: renombra el fichero exactamente como la tabla de destino antes de convertir. Hacerlo al revés significa buscar y reemplazar en cincuenta mil líneas, que funciona hasta el día en que alguien reemplaza la cadena equivocada. Ojo con las tildes y la eñe: un libro llamado «Artículos año 2024» produce un nombre de tabla lleno de guiones bajos donde estaban los acentos.

Los encabezados de la primera fila se convierten en la lista de columnas y pasan por la misma depuración. Una cabecera que ponga «Importe (€)» llega a la sentencia convertida en algo con varios guiones bajos al final, y no coincidirá con la columna de tu tabla.

En un libro escrito en español esto pasa casi siempre, porque las cabeceras suelen llevar acentos, paréntesis o el símbolo de la moneda. Arregla la fila de cabecera en la propia hoja para que diga exactamente los nombres de las columnas de destino, y el fichero generado se ejecuta sin editar una sola línea.

Los números se escriben desnudos. El texto va entre comillas simples y cualquier apóstrofo interior se duplica, que es la forma ANSI portable: un apellido como O Brien con apóstrofo sale correctamente escapado y no rompe la sentencia. No se usa el escapado con barra invertida, porque depende de una configuración del servidor y no de la sentencia.

Una celda vacía se escribe como NULL y no como cadena vacía. Es casi siempre la lectura correcta de un hueco en una hoja, y conviene saberlo si la columna de destino no admite nulos. La distinción entre «no hay» y «no consta» nunca estuvo en el fichero, así que ningún conversor puede recuperarla.

Una celda booleana se escribe con las palabras TRUE o FALSE. PostgreSQL las acepta directamente, MySQL las trata como sinónimos de uno y cero, y SQLite las admite desde hace años. SQL Server no: su tipo de bit espera un 1 y un 0, y la sentencia ni siquiera llega a analizarse.

Sabiéndolo son dos segundos de buscar y reemplazar; descubriéndolo por un error en la sentencia cuatrocientos son veinte minutos de mal humor. Si el destino es SQL Server, haz el reemplazo antes y comprueba que ninguna columna de texto contenga esas palabras. Los identificadores tampoco se entrecomillan, así que una columna que se llame como una palabra reservada del motor hay que arreglarla a mano.

Una hoja de cálculo guarda una fecha y guarda por separado el formato con el que la enseña. El conversor no reformatea nada ni intenta interpretar el calendario, así que lo que aparezca en las sentencias no tiene por qué parecerse a lo que ves en la celda.

Antes de cargar nada, abre el fichero generado y mira una fila que tenga fechas. Si el destino es una columna de fecha y lo que llega no lo es, el error salta enseguida y es fácil de arreglar; si el destino es numérico, la carga funciona y el dato queda mal en silencio, que es el peor de los dos resultados. La costumbre sana es cargar primero en una tabla intermedia y convertir dentro de la base de datos.

Un código guardado como texto en la hoja llega entrecomillado y entero. Un código postal de Álava escrito 01001, un NIF con ceros delante o una referencia de artículo rellena con ceros conservan su forma exacta si la celda era de texto.

Lo que este paso no puede arreglar es el daño previo. Si alguien abrió un CSV en Excel el mes pasado y guardó, esa columna ya es numérica y el cero se perdió antes de que tú llegaras: la sentencia insertará 1001 en tu columna de texto, tan tranquila y tan mal. La pista está en la alineación de la celda, porque el texto se pega a la izquierda y los números a la derecha.

Cada sentencia nombra sus columnas de forma explícita en lugar de fiarse del orden de la tabla, que es lo que permite que el fichero siga funcionando si la tabla gana una columna más adelante. El conjunto de columnas es la unión de todo lo que aparece en la hoja, así que un campo que solo existe a partir de la fila diez mil también está en la lista, con NULL en las filas que no lo traían.

El precio de esa verbosidad es tamaño: el fichero SQL es normalmente mayor que el libro del que sale. De todos los destinos de datos de este sitio es el único que crece respecto al original, y con cincuenta mil filas la diferencia se nota al abrirlo en un editor.

Las sentencias se emiten de una en una, sin transacción alrededor y sin agrupar varias filas en un mismo VALUES. Ejecutadas tal cual contra PostgreSQL o MySQL, eso son cincuenta mil viajes y cincuenta mil confirmaciones, lo bastante lento como para notarse y con la desagradable propiedad de dejar la tabla a medio llenar si algo falla por el camino.

Envolver el fichero entre BEGIN y COMMIT cuesta dos líneas y arregla las dos cosas. Para cargas realmente grandes, la herramienta correcta es la carga masiva del propio motor, que lee un fichero delimitado directamente; para eso conviene convertir a CSV o TSV en lugar de a SQL.

Se lee la primera hoja del libro y nada más. No se leen las demás, ni las fórmulas —de las que llega únicamente el valor calculado que quedó guardado—, ni los formatos numéricos, ni las celdas combinadas, ni los gráficos, ni las anchuras de columna, ni las validaciones, ni los comentarios.

Para este destino casi nada de eso importa, porque una serie de INSERT se dirige a una tabla y una tabla no tiene celdas combinadas. Sí importa saber cuál es la primera: un libro recuerda qué pestaña estaba activa al guardarlo, así que la que se abre en pantalla no siempre es la que se convierte. Si necesitas varias hojas en varias tablas, convierte una vez por hoja renombrando el fichero cada vez.

La lectura del libro y la escritura de las sentencias ocurren en tu navegador, sin ninguna petición que lleve el fichero. En este par eso pesa más que en casi cualquier otro: una hoja camino de una base de datos suele contener clientes, importes, nóminas o datos personales, y pegarla en una web para que la procese un tercero es exactamente el tipo de cesión que luego hay que explicar.

También significa que no hay cola, ni cuenta, ni límite de filas más allá de la memoria de tu equipo. El tope por archivo en las conversiones locales es de 100 MB, que para un .xlsx es un libro enorme.

Es la revisión más rentable que va a tener este fichero. La primera línea te enseña de golpe el nombre de la tabla, la lista completa de columnas y un ejemplo de cómo ha quedado escrito cada tipo de valor, todo en un solo vistazo.

Si esa línea está bien, es muy probable que lo estén las cincuenta mil siguientes, porque todas se generan con las mismas reglas. Si algo chirría —una columna con guiones bajos de más, un TRUE donde esperabas un uno, un cero perdido— lo has visto antes de tocar la base de datos y no después.