¿Qué es un archivo SQL?

SQL es un formato de texto plano que se abre en cualquier editor. Se usa para mover datos entre programas y el archivado.

La extensión es .sql y el nombre completo, SQL Insert Statements. Ambos importan menos que lo que el archivo puede contener, y de eso trata el resto de esta página.

Se remonta a 1986. La especificación es ISO/IEC 9075.

A un formato que lleva tanto tiempo siendo legible se le puede confiar algo que quieras recuperar dentro de diez años.

Está publicada entera, así que cualquiera puede implementarla leyendo el documento en vez de a base de inspeccionar archivos. Por eso aparece en tantos programas, y por eso los archivos escritos hace veinte años siguen abriéndose hoy. Publicada no quiere decir libre de regalías: cuando un formato envuelve un códec, la licencia de las patentes es un asunto aparte que la norma no resuelve.

SQL tiene sintaxis de comentarios, que es la diferencia entre un archivo que mantiene una persona y uno que escribe un programa. Los comentarios son lo primero que se pierde al convertir a un formato que no los tiene, y nada te avisa.

PostgreSQL, MySQL y DBeaver lo leen, y también la mayoría de programas del mismo tipo.

Cuando un archivo no se abre, el formato rara vez es el problema: lo más habitual es que el programa sea anterior al formato. Convertir a algo más antiguo es la salida fiable, y para eso está el resto de este sitio.

Ningún navegador lo lee.

Ese es el motivo más frecuente para convertirlo: no que el formato sea malo, sino que el sitio donde quieres mostrar el archivo no sabe leerlo.

SQL está pensado para abrirse y cambiarse. Guarda el archivo en este formato mientras el trabajo siga en marcha y exporta desde él cada vez que haga falta una copia terminada.

SQL es un lenguaje de consulta estandarizado desde 1986. Un archivo .sql es un archivo de texto con sentencias dentro, y eso es todo el formato: no hay cabecera, no hay estructura y no hay forma de saber por la extensión qué hace un archivo concreto. Puede crear tablas, insertar un millón de filas, modificar un esquema o simplemente guardar tres consultas que alguien quería no perder.

En la práctica los que se intercambian son de dos clases. Un volcado es una base de datos o una tabla escrita como sentencias que la recrean en otro sitio. Una migración es un guion que cambia un esquema de forma controlada. Los dos son texto y los dos se abren en cualquier editor, y confundirlos es la manera habitual de que un guion pensado para añadir una columna acabe borrando una tabla.

Normalmente tres cosas en este orden. Una sentencia que borra la tabla si existe, que es la razón por la que ejecutar un volcado contra una base de datos viva no es un acto reversible. Un CREATE TABLE que define las columnas y sus tipos. Y después las filas, como sentencias INSERT: a veces una por fila y a veces unos cientos de filas agrupadas en una sola sentencia, lo cual carga muchísimo más rápido y se lee muchísimo peor.

Alrededor de eso, un volcado real añade tareas domésticas: declaraciones de juego de caracteres, ajustes que suspenden la reconstrucción de índices mientras entran los datos y una transacción que envuelve el conjunto para que un fallo a media carga no deje nada a medias. Esa parte doméstica es específica de cada base de datos, y es el motivo principal de que un volcado de una no entre en otra.

El estándar define un núcleo y cada base de datos lo amplía. El entrecomillado de identificadores cambia: acentos graves en MySQL, comillas dobles en PostgreSQL, corchetes en SQL Server. Las claves autoincrementales se escriben de tres maneras distintas. Las funciones de fecha, las de texto, el tratamiento de los booleanos y los propios nombres de los tipos divergen.

Así que un volcado de MySQL no entra en PostgreSQL, y el error que da suele ser una queja de sintaxis en la línea cuatro y no una explicación de por qué. Traducir de un dialecto a otro es trabajo real y bastante mecánico; si lo que mueves son datos y no un esquema, pasar por CSV es muy a menudo más rápido y más fiable que traducir el SQL.

En la terminal, cada base de datos trae su cliente y la invocación es corta: psql para PostgreSQL, el cliente mysql para MySQL y MariaDB, sqlite3 para SQLite, los tres tomando el archivo como entrada. Es la vía más rápida con diferencia para un volcado grande, porque una herramienta gráfica que lee el archivo entero en memoria se atasca en cuanto pasa de unos cientos de megabytes.

Dos cosas antes de ejecutarlo. Leer el principio del archivo para ver si borra algo. Y crear antes la base de datos de destino si el volcado no la crea él, porque un volcado escrito para un nombre de base de datos no se inventa otro en silencio.

Suele ser una de cuatro. Un límite de tamaño de sentencia o de paquete, que salta con un INSERT agrupado que lleva varios miles de filas, y que es del servidor y no del archivo. Un tiempo de espera agotado en un cliente gráfico, que en la línea de comandos no tiene equivalente. Un desajuste de juego de caracteres, que aparece como texto destrozado en lugar de como error y conviene detectar pronto. O una clave ajena que rechaza filas que llegan antes que la tabla a la que apuntan.

La última es la más frecuente y la menos evidente. Los volcados suelen resolverla desactivando la comprobación de claves mientras dura la carga, y un volcado editado a mano —unas cuantas tablas sacadas de un archivo mayor— pierde esa protección. Cargar en orden de dependencias, o devolver esa envoltura al archivo, es el arreglo.

Un volcado sirve para recrear una base de datos. Si lo que quieres son los datos —para analizarlos, para abrirlos en una hoja de cálculo, para dárselos a alguien que no administra ninguna base de datos—, el CSV es mejor recipiente, y el Parquet lo es todavía más en cuanto el tamaño empieza a notarse.

La dirección contraria también merece conocerse. Convertir una tabla en sentencias INSERT es la manera habitual de meter datos en una base de datos a la que no tienes conexión directa, situación muy común en alojamientos compartidos: ningún puerto abierto, pero una consola de consultas que ejecuta encantada el archivo que le pegues.

Es texto, así que lo abre cualquier editor. Para algo que vayas a ejecutar merece la pena uno que entienda la sintaxis, porque coloreará las sentencias y hará visible una comilla sin cerrar antes de que la encuentre la base de datos.

Un volcado puede ser enorme, y la forma sensata de inspeccionar uno de varios gigabytes es mirar las primeras y las últimas decenas de líneas en lugar de abrirlo entero. Las primeras dicen el dialecto, el juego de caracteres y si se borra algo; las últimas dicen si el volcado terminó, que es el dato más útil que se puede saber de un archivo que te ha mandado otra persona.

Cuando aquí se convierte una tabla —un CSV, un JSON, una hoja de cálculo— a .sql, lo que sale son únicamente sentencias INSERT INTO … VALUES …; No hay CREATE TABLE, no hay tipos, no hay claves ni índices. Es decir: el archivo carga datos en una tabla que ya tiene que existir, con las columnas ya definidas, y no la construye por ti. Es la forma correcta de entenderlo antes de ejecutarlo contra nada.

Tres detalles más que conviene saber. El nombre de la tabla sale del nombre del archivo de origen, saneado. Los booleanos se escriben TRUE y FALSE, que no es válido en todos los dialectos. Y los identificadores no van entrecomillados, así que un nombre de columna que coincida con una palabra reservada dará guerra. Si los datos de partida están anidados, se aplanan en columnas con el nombre separado por puntos, igual que hacia CSV.

Aquí no existe ninguna conversión que salga de un `.sql`: ni construida ni pendiente de construir, y es el único formato del catálogo del que puede decirse eso, porque es el único declarado ilegible de entrada. Se puede convertir una tabla en un archivo .sql y no al revés, y la razón es que un montón de sentencias INSERT no es una tabla: es un programa que produciría una tabla si algo lo ejecutara, con su dialecto, sus dependencias y su orden.

Para recuperar los datos de un volcado que ya tienes, el camino es el de siempre: cargarlo en la base de datos que le corresponde y exportar desde ahí a CSV. Da más pasos y es la única versión de esa operación que no adivina nada.