SQL, explicado: el lenguaje de consulta al que le encanta verse bien

En pocas palabras

Formatear SQL es la práctica de aplicar reglas de estilo consistentes al código SQL para que a los humanos les resulte más fácil leerlo, debuggearlo y mantenerlo.

El problema que resuelve

El Lenguaje de Consulta Estructurado (SQL) ha sido el rey de la manipulación de datos desde los años 70. Fue diseñado para que las computadoras hablaran con las bases de datos, y hace ese trabajo a la perfección. ¿El detalle? Al motor de la base de datos le da completamente igual cómo se ve tu SQL.

Para una computadora, esto:

SELECT u.id, p.profile_url, COUNT(c.id) AS comment_count FROM users u JOIN profiles p ON u.id = p.user_id LEFT JOIN comments c ON u.id = c.user_id WHERE u.signup_date > '2023-01-01' GROUP BY u.id, p.profile_url HAVING COUNT(c.id) > 5 ORDER BY comment_count DESC;

...es exactamente lo mismo que esto:

select u.id,p.profile_url,count(c.id) as comment_count from users u join profiles p on u.id=p.user_id left join comments c on u.id=c.user_id where u.signup_date>'2023-01-01' group by u.id,p.profile_url having count(c.id)>5 order by comment_count desc;

Esta flexibilidad es genial para la máquina, pero una pesadilla total para el desarrollador humano. A medida que las consultas crecen de simples búsquedas a monstruos con múltiples joins y subqueries, el SQL sin formato se convierte en un muro de texto denso e ilegible. Intentar encontrar un bug o entender la lógica en una consulta de 100 líneas en un solo bloque es una receta para un dolor de cabeza.

El formateo de SQL resuelve este problema humano. Impone una estructura visual que refleja la estructura lógica de la consulta. Al agregar saltos de línea, sangrías y un uso consistente de mayúsculas, transforma un enredo caótico en un documento claro y escaneable. No se trata de hacer el código "bonito" por que sí; se trata de hacerlo comprensible. Es una cortesía profesional para tus compañeros de equipo y, lo más importante, para tu "yo" del futuro que tiene que debuggear este código a las 3 de la mañana.

Cómo funciona por dentro

Un buen formateador de SQL es mucho más que un simple script de buscar y reemplazar. Es una herramienta consciente del lenguaje que analiza y entiende tu código antes de reescribirlo. El proceso generalmente involucra tres pasos principales.

Paso 1: Análisis Léxico (o Tokenización)

Primero, el formateador escanea el texto crudo de tu sentencia SQL y lo descompone en un flujo de "tokens". Un token es la unidad de significado más pequeña del lenguaje. Piénsalo como si dividieras una oración en palabras y signos de puntuación individuales.

Para una consulta simple como SELECT name FROM users;, el flujo de tokens se vería algo así:

Texto del Token	Tipo de Token
`SELECT`	`KEYWORD`
`name`	`IDENTIFIER`
`FROM`	`KEYWORD`
`users`	`IDENTIFIER`
`;`	`PUNCTUATION`

El analizador léxico (lexer) categoriza cada parte de la entrada: palabras clave (SELECT, FROM, WHERE), identificadores (nombres de tablas y columnas como users, name), operadores (=, +, >), literales (cadenas de texto como 'admin' o números como 42), y puntuación. Este flujo de tokens es la materia prima para el siguiente paso.

Paso 2: El Análisis Sintáctico y el Árbol de Sintaxis Abstracta (AST)

La lista de tokens es solo una secuencia plana. Para entender realmente la consulta, el formateador necesita comprender su estructura gramatical. Aquí es donde entra el análisis sintáctico (parsing). El parser toma el flujo de tokens y construye una estructura de datos jerárquica llamada Árbol de Sintaxis Abstracta (AST, por sus siglas en inglés).

El AST representa la estructura lógica del código, de manera muy similar a como un análisis sintáctico de una oración muestra la relación entre un sujeto, un verbo y un objeto.

Para nuestra consulta simple SELECT name FROM users;, el AST podría verse así de forma simplificada:

- SelectStatement
  - SelectClause
    - SelectItem
      - Identifier: "name"
  - FromClause
    - Table: "users"

Para una consulta más compleja con una cláusula WHERE, el AST tendría otra rama para la WhereClause, que a su vez contendría nodos que representan el operador de comparación y los valores que se comparan. Este árbol es el "modelo mental" que el formateador tiene de tu consulta. Ya no ve una cadena de texto; ve una sentencia SELECT con cláusulas y componentes específicos.

Paso 3: Impresión con formato (Pretty-Printing) del Árbol

Aquí es donde ocurre la magia. Con el AST en mano, el formateador ahora puede recorrer el árbol, nodo por nodo, e imprimirlo de nuevo como una cadena de texto, pero esta vez aplicando un conjunto de reglas consistentes.

El "pretty-printer" tiene una regla para cada tipo de nodo en el AST:

Cuando ve un nodo SelectStatement, sabe que debe iniciar una nueva línea.
Cuando encuentra un token KEYWORD como SELECT, una regla determina si va en mayúsculas o minúsculas (p. ej., MAYÚSCULAS).
Cuando entra en una FromClause, sabe que debe imprimir FROM en una nueva línea y aplicar sangría a la siguiente parte.
Cuando encuentra una lista de columnas en la SelectClause, podría tener una regla para poner cada columna en una nueva línea si la lista excede una cierta longitud.
Cuando ve un token de operador, agrega espacios a su alrededor (= se convierte en =).

Al recorrer sistemáticamente el AST y aplicar estas reglas, el formateador construye la salida final y limpia. Este enfoque es poderoso porque no está solo adivinando basándose en patrones de texto. Entiende que user en FROM users es el nombre de una tabla, pero user dentro de 'user_profile.jpg' es solo parte de una cadena de texto y no debe tocarse. También permite que los formateadores manejen diferentes dialectos de SQL (p. ej., PostgreSQL, MySQL, T-SQL), ya que el parser se puede configurar para entender la sintaxis y las palabras clave únicas de cada uno.

Anécdotas de la vida real

El Caso de la Sesión de Debugging a Medianoche

Priya, una ingeniera senior, se despertó de un salto por una alerta de PagerDuty: "CPU de la base de datos al 99%". Inició sesión y encontró la fuente: una única y monstruosa query de SQL ejecutándose en bucle, consumiendo todos los recursos. La query había sido subida una hora antes por un desarrollador junior. Abrió el archivo y se le hundió el corazón. Eran 250 líneas de SQL sin formato, un revoltijo caótico de subqueries anidadas, sentencias case y múltiples JOINs. Era imposible seguir la lógica.

Antes de siquiera intentar entenderla, copió todo ese bloque de texto y lo pegó en un formateador de SQL. Al instante, la bestia fue domada. El resultado formateado, con una sangría y saltos de línea claros, reveló la estructura de la consulta. Y ahí estaba, clarísimo: un JOIN a una tabla masiva al que le faltaba la condición ON, resultando en un catastrófico producto cartesiano. Agregó la cláusula ON correcta, hizo push del fix y vio cómo la CPU de la base de datos volvía a la normalidad.

Lección: Formatear no es solo por estilo; es un primer paso crítico para debuggear. Hace visible la estructura lógica, lo que a menudo revela el bug en el proceso.

La Fusión y el Revoltijo de Estilos

Dos startups se fusionaron y sus equipos de ingeniería se combinaron. El equipo "Acme" escribía SQL todo en mayúsculas, usaba comas al final de las líneas y sangraba con tabuladores. El equipo "Bolt" usaba minúsculas, comas al principio y sangraba con cuatro espacios. Los code reviews se convirtieron en discusiones interminables y pasivo-agresivas sobre estilo. "Detalle: aquí usamos las palabras clave en minúsculas", se convirtió en el comentario más común, desviando por completo las discusiones sobre la lógica y el rendimiento real.

El nuevo líder técnico, harto de las guerras de estilo, implementó una regla simple: todo el código SQL debe pasar por un formateador automático como parte del pipeline de CI/CD antes de poder ser mergeado. Configuró el formateador con una guía de estilo neutral y lo agregó a los hooks de pre-commit. Los debates cesaron de la noche a la mañana. El código base poco a poco se volvió uniforme. Los ingenieros ahora podían centrarse en lo que el código hacía, no en cómo se veía.

Lección: Un formateador automático y compartido es el pacificador definitivo. Impone consistencia, elimina discusiones inútiles y permite que los equipos se concentren en lo que importa.

El Analista que no Podía Copiar y Pegar

Ben, un analista de datos, necesitaba ejecutar una consulta compleja para generar un informe de ventas trimestral. Un ingeniero le envió la consulta por correo electrónico. Pero cuando Ben la copió de su cliente de correo y la pegó en su herramienta de base de datos, era un desastre. El cliente de correo había agregado caracteres > en cada línea, insertado saltos de línea extraños y convertido las comillas tipográficas. La consulta falló con una docena de errores de sintaxis.

Frustrado después de diez minutos de limpiarla manualmente, Ben recordó el portal de herramientas internas. Pegó todo el desastre que copió de su email —caracteres > y todo— en el visualizador de SQL. La herramienta fue lo suficientemente inteligente como para ignorar los artefactos del correo, analizar el SQL subyacente y generar una consulta perfectamente limpia y ejecutable. La ejecutó y obtuvo sus datos en segundos.

Lección: Un formateador robusto es más que un embellecedor; es una herramienta de limpieza que puede rescatar código masacrado por sistemas que no entienden de código, como el correo electrónico o el chat.

Errores y trampas comunes

Ignorar las diferencias entre dialectos. Formatear una consulta de T-SQL de Microsoft usando un conjunto de reglas de PostgreSQL es una mala idea. Un formateador podría "arreglar" TOP 10 cambiándolo a LIMIT 10, lo que causaría un error de sintaxis en SQL Server. Asegúrate siempre de que tu formateador esté configurado para el dialecto de SQL correcto.
Formatear código autogenerado. Ten mucho cuidado al formatear SQL que es construido dinámicamente por un programa o un ORM (Object-Relational Mapper). Esa aplicación podría depender de una estructura de cadena de texto muy específica —y a menudo fea—. "Arreglar" los espacios en blanco podría romper el código que lo genera o lo lee.
Discutir por el estilo "perfecto". El principal beneficio del formateo es la consistencia. Perder horas debatiendo si las palabras clave deben ir en mayúsculas o minúsculas es contraproducente. Elige una configuración predeterminada sensata (como una guía de estilo popular) y deja que la herramienta la imponga.
Confiar en el formateo para arreglar la lógica incorrecta. Un formateador puede hacer que una consulta lenta e ineficiente se vea hermosa. No la hará rápida. El formateo hace que la mala lógica sea visible, pero sigue siendo tu responsabilidad arreglar los problemas de rendimiento o corrección subyacentes.

Por qué deberías tenerlo en el radar

Si trabajas con datos, trabajas con SQL. Y si trabajas con SQL en cualquier capacidad profesional, debería importarte su legibilidad. Deberías pensar en formatear SQL cada vez que:

Escribes una nueva consulta: Formátala antes de hacer commit. Es un regalo para tus colegas.
Revisas el código de otra persona: Si una consulta es difícil de leer, tu primera petición debería ser: "¿Puedes pasar esto por el formateador, por favor?".
Debuggeas una consulta compleja: Ni siquiera intentes leer el código en crudo. Formátalo primero.
Te incorporas a un nuevo proyecto: Busca su guía de estilo de SQL o la configuración del formateador. Es una forma rápida de aprender los estándares del equipo.
Inicias un nuevo proyecto: Establece un estándar de formato desde el primer día y automatízalo en tu pipeline de CI/CD.

En resumen, formatear no es un "extra" opcional. Es una parte fundamental de escribir SQL profesional, mantenible y colaborativo.

Para profundizar

Wikipedia: SQL: La visión general del lenguaje en sí.
dbt Labs SQL Style Guide: Una guía de estilo muy respetada y práctica para escribir SQL en equipos de datos modernos.
SQLFluff Docs: La documentación de un popular linter y formateador de SQL altamente configurable. Su sección de "Reglas" es un gran recorrido por todas las cosas que se pueden configurar.
PostgreSQL: Estructura Léxica: Una inmersión profunda en la gramática oficial y las reglas de tokenización de uno de los dialectos de SQL más populares.