Formateador de SQL

Para qué sirve

Una consulta escrita de un tirón cabe en una línea y no hay quien la lea. El problema no es estético: cuando las cláusulas no se ven separadas, un JOIN de más o una condición que se coló en el sitio equivocado pasan desapercibidos hasta que los números salen mal. Ordenar la consulta es la forma más barata de revisarla.

Esta herramienta reparte las cláusulas por líneas, sangra las subconsultas y unifica la caja de las palabras reservadas. Trabaja en dos pasadas: primero trocea el texto en piezas —cadenas, comentarios, nombres, signos— y solo después decide dónde caen los saltos. Ese orden es lo que garantiza que un literal como «select from where» dentro de unas comillas no se rompa por dentro.

Lo que no hace es entender la consulta. No comprueba la sintaxis, no la ejecuta y no sabe qué tablas existen. Con SQL incompleto devolverá algo con una pinta rara, pero nunca alterado: el contenido de cada pieza se copia carácter a carácter.

Cómo se calcula

La primera pasada recorre el texto de izquierda a derecha reconociendo piezas. Las cadenas y los comentarios se capturan enteros de una vez, porque dentro puede haber cualquier cosa: un punto y coma, un paréntesis o la palabra SELECT que no son sintaxis sino texto. Ahí está la diferencia con los formateadores hechos a base de buscar y reemplazar, que acaban partiendo literales.

La segunda pasada coloca. Las palabras que abren cláusula —SELECT, FROM, WHERE, GROUP BY, ORDER BY, los JOIN— empiezan línea. Los conectores AND y OR también, con un nivel de sangría, para que una condición larga se lea como una lista. Las comas de una lista de columnas cortan línea; las de una llamada a función no, porque ahí solo alargarían.

Los paréntesis se tratan de dos formas distintas según lo que envuelvan. Si dentro empieza un SELECT es una subconsulta: se abre bloque, se sangra y el cierre baja a su línea. Si envuelve argumentos o una lista de valores se queda en línea. Esa distinción es la que hace legible una consulta con subconsultas anidadas.

El cambio de caja solo se aplica a una lista cerrada de palabras reservadas. Cualquier otra cosa —nombres de tabla, de columna, de función— se deja exactamente como estaba, porque hay motores que distinguen mayúsculas y cambiar la caja de un identificador convertiría el formateo en un error.

texto → piezas → maquetado

Nunca se decide un salto de línea mirando el texto en bruto: se decide mirando las piezas ya reconocidas.

'select from where' → una sola pieza, intocable

Lo que hay entre comillas es un dato, aunque se parezca a una consulta.

Ejemplo resuelto

Una consulta de una línea

Entrada: select u.id, count(p.id) as pedidos from usuarios u left join pedidos p on p.usuario_id = u.id where u.activo = true group by u.id

SELECT abre cláusula y la lista tiene dos elementos, así que baja de línea y cada columna se sangra.
El nombre «count» no es palabra reservada: se deja en minúsculas y su paréntesis se queda pegado, porque es una llamada.
FROM y LEFT JOIN empiezan línea cada uno; las tres piezas de la unión se mantienen juntas.
WHERE empieza línea, y «true» sí es palabra reservada, así que pasa a TRUE.
GROUP BY se mantiene como una sola cláusula de dos palabras.

Seis líneas con cada cláusula a la vista, en lugar de una de ciento treinta caracteres.

Qué palabras cambian de caja y cuáles no

La lista de palabras reservadas que se reconocen es amplia, pero deliberadamente incompleta: cada motor añade las suyas y perseguirlas todas no acaba nunca. Una palabra que no esté en la lista se respeta.

El criterio es asimétrico a propósito. Dejar en minúsculas una palabra reservada poco común es un defecto cosmético; poner en mayúsculas lo que resulta ser el nombre de una columna puede romper la consulta en PostgreSQL con identificadores entrecomillados o en MySQL sobre Linux, donde los nombres de tabla distinguen mayúsculas.

Entrada	Salida	Por qué
select	SELECT	palabra reservada conocida
miColumna	miColumna	no está en la lista: se respeta
count(x)	count(x)	los nombres de función no se tocan
"From"	"From"	entrecomillado: es un identificador
'select'	'select'	está dentro de una cadena

Dialectos

Se reconocen los comentarios de los tres estilos habituales: dos guiones, almohadilla y bloque entre barra y asterisco. Para los identificadores valen las comillas dobles del estándar y las tildes invertidas de MySQL, y dentro de una cadena se admiten tanto la comilla duplicada del estándar como la barra invertida que acepta MySQL.

Lo que no se cubre son las extensiones propias de cada motor: bloques PL/pgSQL entre dólares, variables de T-SQL con arroba en contextos raros o sintaxis específica de procedimientos. Se trocean sin perder texto, pero el reparto por líneas de un bloque procedimental no será el que uno esperaría.

Preguntas frecuentes

¿Comprueba si la consulta es correcta?

No. Reparte cláusulas por líneas sin entender lo que dicen, así que una consulta con un error de sintaxis se formatea igualmente. Para saber si es válida hace falta el propio motor, que es el único que conoce sus tablas y su dialecto.

¿Puede estropear una consulta?

No debería: lo único que cambia son los espacios entre piezas y la caja de las palabras reservadas conocidas. El texto de cadenas y comentarios se copia carácter a carácter, y los nombres que no reconoce los deja intactos. Aun así, revisa el resultado antes de ejecutar algo contra producción.

¿Por qué no pone en mayúsculas los nombres de función?

Porque no puede distinguir con seguridad una función del motor de una función tuya o de un nombre de columna. Tocar la caja de un identificador rompe consultas en los motores que la distinguen, y ese riesgo no compensa la mejora estética.

¿Sirve para cualquier base de datos?

Para la sintaxis común de PostgreSQL, MySQL, MariaDB, SQL Server, Oracle y SQLite sí. Las extensiones propias de cada motor, como los bloques de procedimiento, se conservan enteras pero no se reparten bien por líneas.

¿Qué hace la opción de minificar?

Deja la consulta en una sola línea con un espacio entre piezas y elimina los comentarios. Es útil para meterla en un archivo de configuración, en una variable o en un registro donde los saltos de línea molestan. Las cadenas se conservan enteras, con sus espacios.

¿Es seguro pegar una consulta con datos de clientes?

El procesado ocurre entero en esta pestaña, con JavaScript, y no hay ninguna petición de red por medio. Dicho eso, si la consulta lleva datos personales dentro conviene aplicar la misma regla que con cualquier herramienta ajena: usar un ejemplo equivalente cuando se pueda.