SQL es uno de los lenguajes más utilizados en el mundo de los datos. Desde analistas de negocio hasta Data Engineers, prácticamente cualquier profesional que trabaje con información estructurada utiliza SQL a diario para consultar, transformar y analizar datos.

Sin embargo, a medida que los proyectos crecen, las consultas también lo hacen. Lo que comienza como una consulta sencilla puede terminar convirtiéndose en cientos de líneas difíciles de leer, mantener y optimizar.

Escribir SQL que funcione es importante. Escribir SQL limpio, entendible y mantenible es aún más importante.

En este artículo veremos algunas buenas prácticas para mejorar la calidad de nuestras consultas SQL y facilitar el trabajo tanto para nosotros como para el resto del equipo.

¿Por qué es importante escribir SQL limpio?

Cuando desarrollamos consultas, normalmente pensamos en obtener el resultado correcto.

Sin embargo, una consulta rara vez se ejecuta una sola vez.

Con frecuencia ocurre que:

• Otro compañero debe revisarla.
• Necesita modificarse meses después.
• Se convierte en la base de un dashboard.
• Forma parte de un pipeline automatizado.
• Se integra dentro de un proyecto dbt.

Si la consulta es difícil de entender, cualquier modificación futura será más costosa y propensa a errores.

Por este motivo, la legibilidad debe considerarse tan importante como el resultado final.

Utilizar nombres descriptivos

Uno de los errores más comunes consiste en utilizar alias poco claros.

Por ejemplo:

SELECT

    a.id,

    b.name,

    c.total

FROM t1 a

JOIN t2 b

    ON a.id = b.id

JOIN t3 c

    ON a.id = c.id

Aunque técnicamente es correcto, resulta complicado entender qué representa cada tabla.

Una versión más legible sería:

SELECT

    customers.customer_id,

    customers.customer_name,

    orders.order_total

FROM customers

JOIN customer_details

    ON customers.customer_id = customer_details.customer_id

JOIN orders

    ON customers.customer_id = orders.customer_id

Los nombres descriptivos facilitan enormemente la comprensión de la consulta.

Dar formato al código

El formato influye mucho más de lo que parece.

Una consulta mal estructurada puede resultar difícil de leer incluso para quien la escribió originalmente.

Por ejemplo:

SELECT customer_id,customer_name,total_sales

FROM customers

WHERE country=’Spain’

AND total_sales>1000

ORDER BY total_sales DESC

La misma consulta con un formato adecuado:

SELECT

    customer_id,

    customer_name,

    total_sales

FROM customers

WHERE country = ‘Spain’

    AND total_sales > 1000

ORDER BY total_sales DESC

El resultado es mucho más claro.

Utilizar CTEs para dividir la lógica

Cuando una consulta comienza a crecer, una de las mejores prácticas consiste en utilizar Common Table Expressions (CTEs).

Los CTEs permiten dividir procesos complejos en bloques más fáciles de entender.

Por ejemplo:

WITH customer_sales AS (

    SELECT

        customer_id,

        SUM(total_amount) AS total_sales

    FROM orders

    GROUP BY customer_id

)

SELECT *

FROM customer_sales

WHERE total_sales > 1000

Este enfoque facilita:

• Leer la lógica.
• Reutilizar resultados intermedios.
• Depurar errores.
• Mantener el código.

Evitar SELECT *

Utilizar SELECT * puede parecer cómodo, pero rara vez es una buena práctica en entornos productivos.

Por ejemplo:

SELECT *

FROM customers

El problema es que:

• Recupera columnas innecesarias.
• Aumenta el volumen de datos procesados.
• Puede generar errores cuando cambia la estructura de la tabla.

Es preferible especificar únicamente las columnas necesarias:

SELECT

    customer_id,

    customer_name,

    country

FROM customers

Esto mejora tanto la legibilidad como el rendimiento.

Documentar consultas complejas

No todas las consultas son sencillas.

En ocasiones es necesario implementar reglas de negocio complejas o cálculos difíciles de interpretar.

En estos casos, los comentarios pueden resultar muy útiles.

Por ejemplo:

— Clientes con más de 12 meses de antigüedad

SELECT

    customer_id,

    customer_name

FROM customers

WHERE registration_date < CURRENT_DATE – INTERVAL ’12 months’

Los comentarios ayudan a transmitir la intención de la consulta.

Mantener una estructura consistente

Los equipos más eficientes suelen seguir convenciones comunes.

Por ejemplo:

SELECT

FROM

JOIN

WHERE

GROUP BY

HAVING

ORDER BY

Siempre en el mismo orden y formato.

Esta consistencia facilita enormemente la revisión y mantenimiento del código.

Evitar lógica innecesariamente compleja

A veces encontramos consultas con múltiples niveles de subconsultas anidadas que dificultan la comprensión.

Por ejemplo:

SELECT *

FROM (

    SELECT *

    FROM (

        SELECT *

        FROM sales

    )

)

Aunque funcione, no aporta ningún valor.

Siempre que sea posible, conviene simplificar la lógica.

Un código más sencillo suele ser más fácil de mantener y optimizar.

Utilizar alias de forma inteligente

Los alias pueden mejorar considerablemente la legibilidad cuando se utilizan correctamente.

Por ejemplo:

SELECT

    c.customer_name,

    o.order_date,

    o.total_amount

FROM customers c

JOIN orders o

    ON c.customer_id = o.customer_id

En consultas con múltiples tablas, los alias cortos pero descriptivos ayudan a reducir ruido visual.

Separar transformaciones en etapas

Cuando una consulta realiza muchas transformaciones simultáneamente, suele ser preferible dividir el proceso.

Por ejemplo:

WITH sales AS (

    SELECT *

    FROM orders

),

monthly_sales AS (

    SELECT

        DATE_TRUNC(‘month’, order_date) AS month,

        SUM(total_amount) AS revenue

    FROM sales

    GROUP BY 1

)

SELECT *

FROM monthly_sales

Esta aproximación permite entender claramente cada paso del proceso.

Pensar en quien leerá el código

Una buena pregunta antes de finalizar una consulta es:

«¿Podría entender esto alguien del equipo dentro de seis meses?»

Si la respuesta es no, probablemente merece una revisión.

El SQL no debe escribirse únicamente para las máquinas.

También debe escribirse para las personas.

SQL limpio y Analytics Engineering

La importancia de escribir SQL limpio ha aumentado con la popularidad del Analytics Engineering.

Herramientas como dbt promueven prácticas propias de la ingeniería de software:

• Modularidad.
• Reutilización.
• Testing.
• Documentación.
• Control de versiones.

En este contexto, la calidad del código SQL adquiere una relevancia mucho mayor.

Una consulta mal estructurada puede afectar a múltiples modelos aguas abajo.

Errores frecuentes al escribir SQL

Existen algunos patrones que conviene evitar.

Consultas excesivamente largas

Cuando una consulta supera varios cientos de líneas, suele ser una señal de que podría dividirse en componentes más pequeños.

Alias ambiguos

Alias como:

a

b

c

d

dificultan enormemente la lectura.

Falta de comentarios

Especialmente en reglas de negocio complejas.

Uso abusivo de subconsultas

Los CTEs suelen proporcionar una alternativa más legible.

Seleccionar más datos de los necesarios

Incrementa el consumo de recursos y dificulta el mantenimiento.

Beneficios de un SQL más limpio

Adoptar estas prácticas aporta ventajas importantes.

Mejor mantenimiento

Las modificaciones futuras resultan más sencillas.

Menor riesgo de errores

La lógica es más fácil de validar y revisar.

Mayor colaboración

Otros miembros del equipo pueden comprender el código rápidamente.

Mejor rendimiento

Las consultas suelen ser más eficientes cuando se diseñan cuidadosamente.

Mayor escalabilidad

Resulta más sencillo ampliar modelos y procesos existentes.

SQL limpio en entornos modernos de datos

Actualmente, SQL se encuentra en el centro de muchas plataformas modernas.

Herramientas como:

• Snowflake.
• BigQuery.
• Databricks.
• Redshift.
• Fabric.
• dbt.

dependen en gran medida de consultas SQL para transformar información.

A medida que los equipos gestionan modelos más complejos, la calidad del código se convierte en un factor clave para el éxito de los proyectos.

Conclusión

Escribir SQL limpio no consiste únicamente en seguir normas estéticas. Se trata de crear consultas más fáciles de entender, mantener y evolucionar con el tiempo.

Utilizar nombres descriptivos, estructurar correctamente el código, apoyarse en CTEs, evitar complejidad innecesaria y documentar la lógica son prácticas que aportan valor tanto a nivel individual como de equipo.

En un entorno donde los datos desempeñan un papel cada vez más estratégico, dedicar tiempo a mejorar la calidad del SQL es una inversión que genera beneficios a largo plazo y contribuye a construir plataformas analíticas más robustas y sostenibles.