Buenas prácticas de SQL: consultas legibles y fáciles de mantener

Lección 10.1 · Tiempo de lectura: ~8 min

Las buenas prácticas de SQL son los hábitos de formato y de nombres que hacen que una consulta sea fácil de leer, revisar y cambiar. En esta lección aprenderás a disponer las cláusulas y las columnas, a nombrar tablas, columnas y alias, cuándo ayudan los comentarios, qué hábitos evitan errores y cómo convertir una consulta de una sola línea en código que tu equipo pueda mantener.

En el módulo anterior trabajaste con vistas y tablas temporales, y tus consultas crecieron hasta tener muchas uniones y varios pasos. Con ese tamaño, la calidad del código importa tanto como que sea correcto: el SQL se lee muchas más veces de las que se escribe, tus compañeros en la revisión y tú mismo unas semanas después.

Un código bien estructurado hace visibles los errores, acelera las revisiones y facilita ampliar las consultas. Ninguna de estas reglas cambia lo que hace la base de datos; cambian lo rápido que una persona entiende la consulta.

Por qué importa el estilo del código

Una consulta de 5 a 10 líneas se entiende de un vistazo. Un informe con muchos JOIN, subconsultas o CTE no, y un estilo coherente te ayuda a:

• Encontrar errores más rápido: un filtro equivocado o una condición de unión que falta se notan enseguida en un código limpio.
• Ampliar las consultas con seguridad: una columna o condición nueva tiene un lugar evidente.
• Trabajar en equipo: todos leen el código con la misma disposición, y las revisiones se centran en la lógica y no en el estilo.

Formato e indentación

SQL ignora los espacios y las mayúsculas de las palabras clave, así que la disposición depende de ti. Estas son las convenciones más usadas.

Palabras clave en mayúsculas

Escribe las palabras clave de SQL (SELECT, FROM, WHERE, JOIN, GROUP BY) en mayúsculas y los nombres en minúsculas. Así la estructura de la consulta destaca sobre los datos que usa.

-- Difícil de recorrer
select title, rental_rate from film where rating = 'G';

-- Más fácil de recorrer
SELECT title, rental_rate
FROM film
WHERE rating = 'G';

Resultado: ambas consultas devuelven las mismas 178 películas; solo cambia la disposición.

Una cláusula por línea

Empieza cada cláusula principal en una línea nueva. Cuando SELECT o GROUP BY tienen muchas columnas, pon cada una en su propia línea, con sangría:

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

Con una columna por línea, agregar o quitar una columna cambia una sola línea, y el diff de la revisión muestra exactamente esa línea.

Convenciones de nombres

Minúsculas y snake_case

El estándar de facto son nombres en minúsculas con guiones bajos entre las palabras: customer_orders, total_amount, no CustomerOrders ni TotalAmount. Las bases de datos tratan de forma distinta las mayúsculas de los identificadores: PostgreSQL convierte a minúsculas los nombres sin comillas, y MySQL en Linux distingue mayúsculas y minúsculas en los nombres de tablas. snake_case evita estas sorpresas.

Prefijos coherentes

Algunos equipos marcan los tipos de objeto con prefijos, como v_ para las vistas (v_active_customers) y tmp_ para las tablas temporales (tmp_monthly_report). Sakila no usa prefijos: sus vistas se llaman customer_list, film_list, sales_by_film_category. Ambas opciones funcionan; lo importante es elegir una sola regla para toda la base.

SELECT category, total_sales
FROM sales_by_film_category
ORDER BY total_sales DESC
LIMIT 3;

Resultado: las tres categorías con más ventas: Sports, Sci-Fi y Animation.

Alias claros

Alias de tablas

Usa alias cortos pero con significado, como las primeras letras del nombre de la tabla. Los alias como t1, t2, a, b obligan al lector a averiguar qué significa cada uno:

-- Poco claro: ¿qué son t1 y t2?
SELECT t1.first_name, t2.amount
FROM customer t1
JOIN payment t2 ON t1.customer_id = t2.customer_id;

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

Nombres para columnas calculadas

Ponle nombre a cada agregación y expresión con AS. Una columna de informe llamada COUNT(*) es difícil de usar en una aplicación o una hoja de cálculo:

SELECT
    c.name AS category_name,
    COUNT(*) AS film_count,
    AVG(f.replacement_cost) AS avg_replacement_cost
FROM film f
JOIN film_category fc ON f.film_id = fc.film_id
JOIN category c ON fc.category_id = c.category_id
GROUP BY c.name
ORDER BY film_count DESC;

Resultado: 16 categorías con nombres de columnas claros; Sports tiene más películas, 74.

Comentarios

Los comentarios explican por qué el código hace algo cuando la razón no se ve en el propio código: una regla de negocio, un filtro poco habitual, un problema conocido en los datos.

• Los comentarios de una línea (--) explican un filtro o una fórmula.
• Los comentarios de bloque (/* ... */) describen el propósito de un script.

/*
  Informe: gasto de los clientes en julio de 2005
  Lo usa: el boletín mensual de marketing
*/
SELECT
    customer_id,
    SUM(amount) AS july_spent
FROM payment
WHERE payment_date >= '2005-07-01'  -- todo el mes,
  AND payment_date < '2005-08-01'   -- incluido el 31 de julio después de medianoche
GROUP BY customer_id
ORDER BY july_spent DESC;

Resultado: 599 clientes con su gasto de julio de 2005.

No comentes lo que el código ya dice: -- selecciona customer id encima de SELECT customer_id solo agrega ruido, y los comentarios desactualizados son peores que no tener ninguno.

Hábitos que hacen más seguras las consultas

• Enumera las columnas necesarias en lugar de usar SELECT * en informes, vistas y código de aplicaciones. Así una columna nueva en la tabla no puede cambiar ni ralentizar tu resultado.
• Usa JOIN ... ON explícito en lugar de enumerar tablas separadas por comas en FROM. La condición de unión queda junto a la tabla y es más difícil olvidarla.
• Prefiere rangos de fechas semiabiertos (>= inicio AND < fin) a BETWEEN en columnas de fecha y hora, como en el ejemplo anterior.
• Acuerda un estilo y automatízalo. Los formateadores y linters como SQLFluff aplican las reglas por ti, y en las revisiones ya no se discute sobre espacios.

Ejemplo práctico: limpiar una consulta desordenada

Antes: todo en una línea, sin nombres para las columnas calculadas:

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: una cláusula por línea, uniones alineadas, columnas con nombre:

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;

Resultado: ambas versiones devuelven las mismas 16 películas alquiladas más de 30 veces, encabezadas por BUCKET BROTHERHOOD con 34 alquileres.

En la segunda versión se ve de un vistazo qué tablas se unen y cómo, qué se cuenta y cómo se filtra y ordena el resultado.

Conclusiones clave:

• Escribe las palabras clave en mayúsculas y los nombres en minúsculas, en snake_case.
• Empieza cada cláusula en una línea nueva y escribe las listas largas de columnas una por línea.
• Usa alias de tablas con significado y nombra cada columna calculada con AS.
• Comenta el porqué, no el qué: reglas de negocio y filtros poco evidentes.
• Enumera las columnas en lugar de SELECT *, usa JOIN ... ON explícito y rangos de fechas semiabiertos.
• Acuerda un único estilo en el equipo y aplícalo con un formateador o un linter.

Preguntas frecuentes

¿Las palabras clave de SQL tienen que ir en mayúsculas?

No. Las bases de datos aceptan las palabras clave en cualquier combinación de mayúsculas y minúsculas. Las mayúsculas son una convención que hace más visible la estructura de las consultas largas; lo más importante es que todo el equipo use el mismo estilo.

¿Qué hace que el código SQL sea fácil de mantener?

Un formato coherente, nombres y alias claros, columnas calculadas con nombre y comentarios breves donde la lógica no es evidente. Ese código es más fácil de revisar, cambiar y depurar, también para quien no lo escribió.

¿Por qué evitar SELECT * en las consultas de producción?

SELECT * devuelve todas las columnas, incluidas las que se agreguen a la tabla más adelante. Eso puede romper aplicaciones que esperan un conjunto fijo de columnas, transferir más datos de los necesarios e impedir el uso de índices de cobertura. Enumera las columnas que necesitas.

¿Cómo limpio una consulta SQL desordenada?

Divídela en cláusulas en líneas separadas (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY), pon sangría en las listas de columnas, cambia los alias poco claros, ponle nombre a las columnas calculadas y agrega un comentario donde la lógica necesite explicación. Ejecuta la versión antigua y la nueva para comprobar que los resultados coinciden.