Lesión 10.1 · Tiempo de lectura: ~9 min

Esta lección cubre los conceptos básicos de escribir código SQL de alta calidad que sea fácil de leer y mantener. Aprenderás estándares de formateo, reglas de nomenclatura de objetos y cómo usar comentarios de manera efectiva. Revisaremos cómo hacer que las consultas complejas sean claras para tus compañeros de equipo y para tu futuro yo. Al final de esta lección, podrás formatear scripts SQL de manera profesional y consistente.

Lección 10.1: Mejores Prácticas para un Código SQL Legible y Mantenible

En el módulo anterior, estudiamos herramientas de datos avanzadas como vistas y tablas temporales. Ahora que tus consultas están volviéndose más grandes y complejas, la calidad del código se convierte en una prioridad principal. En el trabajo real de análisis y desarrollo, el código SQL se lee con mucha más frecuencia de la que se escribe.

Un código bien estructurado reduce errores, simplifica la depuración y ahorra tiempo para todo el equipo. Esto no se trata solo de estilo. Es una habilidad crítica para cualquier desarrollador SQL o analista de datos.

Por qué importa el estilo del código

Cuando una consulta tiene de 5 a 10 líneas, su lógica suele ser clara de un vistazo. Pero cuando pasas a informes complejos con muchas cláusulas JOIN, subconsultas o bloques CTE, el código puede volverse sobrecargado y difícil de analizar, incluso para el autor original una semana después.

Seguir estándares te ayuda a:

• Encontrar errores más rápido: filtros incorrectos o cláusulas JOIN faltantes destacan en un código limpio.
• Escalar soluciones: el código estructurado es más fácil de extender con nuevos campos y condiciones.
• Trabajar en equipo: los compañeros de equipo pueden revisar y mantener tus scripts con menos fricción.

Formateo e indentación

Un estilo de formateo consistente es la base de la legibilidad. SQL no es sensible a los espacios en blanco o a la capitalización de letras, pero hay convenciones ampliamente aceptadas.

Capitalización de palabras clave

Una práctica común es escribir las palabras clave SQL (SELECT, FROM, WHERE, JOIN, GROUP BY) en mayúsculas. Esto separa visualmente los comandos de la base de datos de los nombres de tablas y columnas.

-- Pobre
select name, price from products where category_id = 1;

-- Mejor
SELECT name, price
FROM products
WHERE category_id = 1;

Saltos de línea e indentación

Cada cláusula principal debe comenzar en una nueva línea. Si SELECT o GROUP BY incluye muchas columnas, coloca cada columna en su propia línea.

SELECT 
    customer_id,
    first_name,
    last_name,
    email
FROM customer
WHERE active = 1
ORDER BY last_name;

Convenciones de nomenclatura

Elegir buenos nombres para tablas, columnas y variables es esencial para la claridad del código.

Minúsculas y snake_case

En SQL, un estándar de facto es usar minúsculas y guiones bajos entre palabras. Muchos motores de DBMS normalizan la capitalización de identificadores de manera diferente (por ejemplo, PostgreSQL y Oracle), y snake_case ayuda a evitar confusiones.

• Pobre: CustomerOrders, TotalAmount
• Mejor: customer_orders, total_amount

Prefijos para tipos de objetos

A veces, los equipos utilizan prefijos para identificar rápidamente los tipos de objetos.

Ejemplos:

• v_ para vistas: v_active_customers
• tmp_ para tablas temporales: tmp_monthly_report
• t_ para tablas base (menos común)

-- Está claro de inmediato que esta es una vista preparada
SELECT * 
FROM v_customer_payment_summary
WHERE total_amount > 100;

Nombres y alias

Nombres y alias claros hacen que las consultas sean auto-documentadas.

Alias de tabla claros

Usa alias cortos pero significativos, especialmente con JOIN. Evita alias como t1, t2, a, b.

-- Poco claro
SELECT 
    t1.name, 
    t2.amount
FROM table_a t1
JOIN table_b t2 ON t1.id = t2.ref_id;

-- Claro
SELECT 
    c.first_name, 
    p.amount
FROM customer c
JOIN payment p ON c.customer_id = p.customer_id;

Alias claros para campos calculados

Siempre da nombres significativos a agregados y columnas calculadas. Una columna de informe llamada count(*) se ve poco profesional.

SELECT 
    category_id,
    COUNT(*) AS total_films_in_category,
    AVG(replacement_cost) AS average_replacement_cost
FROM film
GROUP BY category_id;

Comentando el código SQL

Los comentarios explican por qué existe una pieza de lógica cuando la intención no es obvia.

• Comentarios de una línea (--): explican filtros o fórmulas específicas.
• Comentarios en bloque (/* ... */): describen el propósito del script, autor y fecha.

/*
  Script: Gasto mensual de clientes activos
  Autor: Ivanov I.
  Fecha: 2026-04-16
*/

SELECT 
    customer_id,
    SUM(amount) AS monthly_spent
FROM payment
WHERE payment_date >= '2026-01-01' -- Filtro desde el inicio del año
  AND payment_date < '2026-02-01'
GROUP BY customer_id;

Ejemplo práctico: limpiando una consulta desordenada

Compararemos una consulta difícil de leer con una versión mantenible.

Antes (difícil de leer):

select f.title,c.name,count(r.rental_id) from film f join film_category fc on f.film_id=fc.film_id join category c on fc.category_id=c.category_id join inventory i on f.film_id=i.film_id join rental r on i.inventory_id=r.inventory_id group by f.title,c.name having count(r.rental_id)>30 order by count(r.rental_id) desc;

Después (fácil de mantener):

SELECT 
    f.title,
    c.name AS category_name,
    COUNT(r.rental_id) AS rental_count
FROM film f
JOIN film_category fc ON f.film_id = fc.film_id
JOIN category c       ON fc.category_id = c.category_id
JOIN inventory i      ON f.film_id = i.film_id
JOIN rental r         ON i.inventory_id = r.inventory_id
GROUP BY f.title, c.name
HAVING COUNT(r.rental_id) > 30
ORDER BY rental_count DESC;

Nota: en la segunda versión, la estructura de relaciones, la nomenclatura de agregados y la lógica de filtros son inmediatamente visibles.

Conclusiones clave de esta lección:

• Escribe palabras clave SQL en mayúsculas para hacer visible la estructura de la consulta.
• Usa saltos de línea e indentación para que las consultas largas sean más fáciles de leer y revisar.
• Usa alias claros para tablas y campos calculados.
• Aplica reglas de nomenclatura consistentes como snake_case para tablas y columnas.
• Comenta la lógica de negocio no obvia y las condiciones de filtro complejas.
• Mantén una guía de estilo compartida en tu equipo para acelerar la revisión, depuración y evolución.

Preguntas Frecuentes

¿Las palabras clave SQL siempre deben estar en mayúsculas?

No existe un requisito técnico. Los motores de DBMS también analizarán en minúsculas. Pero un estilo consistente en mayúsculas (SELECT, FROM, WHERE, JOIN) mejora la legibilidad y acelera la revisión de consultas largas.

¿Cuándo son realmente útiles los comentarios en SQL?

Los comentarios son más útiles donde la lógica no es obvia: reglas de negocio, filtros inusuales y restricciones técnicas. Si el código ya es claro, evita comentarios innecesarios.

¿Qué importa más para la mantenibilidad: el formateo o la nomenclatura?

Ambos son críticos. El formateo muestra rápidamente la estructura de la consulta, mientras que los nombres y alias claros hacen que la intención sea obvia sin necesidad de explicaciones adicionales.

Preguntas de Entrevista

¿Qué características definen un código SQL mantenible?

El SQL mantenible tiene un formateo consistente, nomenclatura clara, alias significativos y comentarios concisos en lugares no obvios. Esto hace que el código sea más fácil de revisar, modificar y soportar en equipos.

¿Por qué una mala nomenclatura puede convertirse en un problema a nivel de equipo?

Nombres y alias poco claros ralentizan las revisiones y aumentan el riesgo de errores durante los cambios. Buenos nombres reducen la carga cognitiva y hacen que la lógica de la consulta sea transparente.

¿Cómo mejorarías una consulta SQL desordenada en la práctica?

Primero, divídela en bloques lógicos (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY) con los saltos de línea e indentación adecuados. Luego, reemplaza los alias poco claros, nombra claramente los campos calculados y agrega comentarios breves donde la lógica no sea obvia.

En la próxima lección, pasaremos a la optimización técnica y aprenderemos a escribir consultas SQL que no solo sean limpias, sino también rápidas.

-> Lección 10.2: Escribiendo Consultas SQL Eficientes