Formateador de SQL online

¿Qué es un formateador de SQL?

Formatear SQL es reescribir la disposición de una consulta — dónde empieza cada línea, cuánto se sangra cada nivel, si las palabras clave van en mayúsculas — sin tocar ni una coma de lo que esa consulta realmente hace. La necesitas cuando el SQL con el que trabajas no lo escribiste tú con ese cuidado: una consulta pegada del registro lento de la base de datos, una que generó un ORM en una sola línea interminable, o un SELECT heredado de tres años atrás que llegó a un informe sin una sola sangría.

En los tres casos el problema es el mismo: el texto es correcto pero ilegible, y leerlo mal cuesta minutos que un formateador ahorra en el momento de pegarlo. Este formateador de SQL online hace exactamente eso — nada más — y lo hace mientras escribes, en el propio navegador.

Cómo se usa

1. Pega tu SQL en el panel izquierdo. El resultado formateado aparece a la derecha al instante, con un contador de cuántos elementos se copiaron intactos.
2. Elige dialecto, sangría y mayúsculas. El dialecto decide cómo se leen las comillas y los identificadores; la sangría y las mayúsculas son solo estilo, y puedes cambiarlos las veces que quieras.
3. Copia el resultado con un clic. El botón de copiar deja el SQL formateado listo para pegar donde lo necesites, sin que nada haya salido de tu navegador.

Por qué «correcto» no está definido, y qué se garantiza en su lugar

No existe una especificación de formateo de SQL. XML tiene la suya, y Markdown tiene CommonMark con 652 ejemplos resueltos que fijan cómo se interpreta cada caso, pero dónde se corta una cláusula, cuánto se sangra una subconsulta o si una palabra clave va en mayúsculas son decisiones de estilo de casa, no reglas del lenguaje. Cualquier herramienta que anuncie un porcentaje de acierto en el formateo se lo ha inventado, porque no hay contra qué medirlo.

Lo que sí se puede garantizar — y esta herramienta garantiza — es que formatear nunca cambia lo que hace la consulta. Cada literal de texto, cada identificador entrecomillado y cada comentario sale byte a byte igual que entró; y la secuencia de elementos de la consulta no cambia, sin que se añada, se pierda ni se reordene ninguno. Lo único que se mueve es el espacio en blanco entre elementos, y lo único que cambia de caja son las palabras clave.

Esto no queda en una promesa: está comprobado por una prueba que compara la secuencia de elementos antes y después de formatear, sobre un corpus escrito a mano y sobre un barrido generado de 1.500 sentencias en los cuatro dialectos, incluyendo un caso de control que demuestra que la comparación es capaz de fallar cuando algo sí cambia. En total son 1.802 comprobaciones.

Importa en la práctica, no solo en teoría: un formateador que corta línea en cada coma la cortará también dentro de un literal de texto, partiendo un dato tuyo en dos líneas. Uno que pone en mayúsculas toda palabra clave pondrá en mayúsculas la palabra select dentro de una cadena, o dentro de una columna que se llame precisamente «select». Ninguna de las dos cosas es un detalle de estilo — ambas cambian el resultado de la consulta, no solo su aspecto.

El selector de dialecto no es gusto: es lo que evita corromper la consulta

El selector de dialecto — Estándar, MySQL, SQL Server, PostgreSQL — elige las reglas de entrecomillado, que es el único punto donde equivocarse no solo desordena el resultado, sino que lo corrompe. MySQL entrecomilla identificadores con acentos graves y trata la almohadilla como inicio de un comentario de línea. SQL Server los entrecomilla con corchetes, de modo que una palabra reservada entre corchetes es simplemente el nombre de una columna. PostgreSQL y el SQL estándar usan comillas dobles, y PostgreSQL añade además cuerpos entrecomillados con signos de dólar, cuyo contenido puede incluir puntos y comas, comillas y prácticamente cualquier cosa sin que se interprete como SQL.

Lee una consulta de MySQL con acentos graves aplicando las reglas del estándar y esos acentos parecerán puntuación corriente en vez de comillas. Lee el cuerpo de una función de PostgreSQL sin soporte de comillas de dólar y su contenido se destroza como si fuera SQL normal. No hay un valor por defecto que sea seguro para los cuatro casos, y por eso la herramienta pregunta en vez de asumir uno.

La limitación honesta que hay que decir es que las reglas de disposición son deliberadamente pocas: las palabras clave de cláusula empiezan línea, los JOIN se sangran un nivel bajo ellas, los paréntesis abren un nivel y las comas cortan la línea. Es un conjunto de reglas más pequeño que el de otras herramientas, y responde exactamente al mismo principio que la garantía anterior — conservar lo que no se entiende en vez de adivinarlo.

Por eso todo lo que el formateador no reconoce pasa tal cual al resultado en lugar de forzarse a encajar en una plantilla que podría estar equivocada para ese fragmento.

¿Por qué es gratis?

Formatear texto es trabajo que tu propio navegador puede hacer sin ayuda de ningún servidor, así que no hay ninguna razón para que este SQL viaje a ningún sitio antes de volver formateado. Todo el análisis y la reescritura ocurren en la pestaña donde estás, con la página ya cargada.

No hace falta crear una cuenta, no se guarda ningún historial y el resultado no lleva ninguna marca de agua ni referencia a la herramienta. El SQL que pegas — que puede venir de un cliente, de un informe interno o de cualquier sistema con datos que no quieres mover de sitio — nunca sale de tu navegador.