7 buenas prácticas de SQL que todo desarrollador debería conocer

Escribir SQL no es difícil; lo difícil es escribirlo bien.

Las consultas que funcionan bien en desarrollo empiezan a ir lentas en producción. Un ORDER BY que falta devuelve resultados inconsistentes, un SELECT * rápido se rompe cuando cambia el esquema, y filtros que parecen inofensivos en un conjunto de datos pequeño pueden quedarse atorados a gran escala.

Con el tiempo empiezas a ver qué patrones funcionan y cuáles no.

Así que aquí tienes siete buenas prácticas de SQL, de parte del equipo detrás de Beekeeper Studio, la GUI de bases de datos moderna, de código abierto y multiplataforma.

🔖 Referencia rápida: Mientras aprendes estas buenas prácticas, ten a la mano nuestra guía rápida del lenguaje SQL para consultar SELECT, WHERE, JOINs, agregaciones y otros comandos esenciales de SQL.

Descarga Beekeeper Studio

1. Sé específico: evita SELECT *

Traer todas las columnas con SELECT * puede parecer rápido y flexible. No tienes que decidir qué columnas devolver y cuáles excluir, y funciona bien cuando todavía estás explorando un conjunto de datos.

Esa flexibilidad tiene un costo. A medida que el esquema evoluciona o los joins se multiplican, SELECT * puede traer columnas duplicadas o inesperadas, hacer más lentas tus consultas y complicar la depuración.

Elegir columnas específicas deja clara la intención y protege tu código de fallas silenciosas.

-- Risky
SELECT * FROM user_profiles WHERE user_id = 42;

-- Better
SELECT user_id, display_name, avatar_url
FROM user_profiles
WHERE user_id = 42;

2. Usa CTEs para simplificar la lógica compleja

Las subconsultas anidadas funcionan, pero rápidamente se vuelven ilegibles. Cuesta ver qué se filtra dónde, y depurar suele significar desplazarte de un lado a otro entre capas de paréntesis.

Las Common Table Expressions (cláusulas WITH) te permiten dividir una consulta en pasos con nombre. Cada paso se puede ejecutar y probar por separado, lo que aclara la intención y facilita rastrear errores. Solo recuerda que algunas bases de datos materializan los CTEs, así que las subconsultas en línea pueden ser más rápidas en ciclos intensivos.

-- Hard to follow
SELECT customer_id, COUNT(*)
FROM (
  SELECT customer_id, created_at
  FROM orders
  WHERE created_at > now() - interval '7 days'
) o
GROUP BY customer_id;

-- Clearer
WITH recent_orders AS (
  SELECT customer_id, created_at
  FROM orders
  WHERE created_at > now() - interval '7 days'
)
SELECT customer_id, COUNT(*)
FROM recent_orders
GROUP BY customer_id;

3. Comenta tu intención, no tu sintaxis

Los comentarios que repiten lo que el SQL ya muestra no aportan mucho. El contexto que realmente vas a olvidar no es qué hace la consulta, sino por qué existe.

Una nota breve sobre su propósito o uso facilita retomar el código o pasárselo a alguien más. Escribe para tu yo del futuro o para el siguiente desarrollador que intente entender por qué importa esta consulta.

-- Find users who signed up but never activated
-- Used in the weekly retention cohort report
SELECT u.id, u.email
FROM users u
LEFT JOIN events e
  ON u.id = e.user_id
  AND e.name = 'account_activated'
WHERE e.id IS NULL
  AND u.created_at > now() - interval '7 days';

4. Haz que tus filtros aprovechen los índices

Los índices solo ayudan cuando tus filtros son sargables (de Search ARGument ABLE). En la práctica, significa que la base de datos puede usar el índice directamente en lugar de recorrer cada fila.

Si envuelves una columna en una función, por ejemplo LOWER(email) o DATE(created_at), el optimizador no puede usar el índice. Incluso las conversiones de tipo pueden tener el mismo efecto. La consulta sigue funcionando, pero se vuelve más lenta conforme crecen tus datos.

-- Not sargable: disables index
WHERE LOWER(email) = 'test@example.com';

-- Sargable: uses existing index
WHERE email = 'test@example.com';

Para mantener tus filtros eficientes, escríbelos de acuerdo con cómo se almacenan los datos. Si necesitas comparaciones sin distinguir mayúsculas y minúsculas, guarda los valores en un formato consistente o agrega un índice funcional. Para fechas, filtra por rango en lugar de transformar la columna: es más claro y el índice sigue en juego.

-- Not sargable
WHERE DATE(created_at) = '2025-08-04';

-- Sargable
WHERE created_at >= '2025-08-04'
  AND created_at <  '2025-08-05';

5. Filtra antes de hacer join

Es tentador unir todo primero y filtrar después, sobre todo al explorar o hacer prototipos. Pero cada join multiplica filas, y cada fila innecesaria hace tu consulta más lenta y más difícil de planear para el optimizador.

En cambio, reduce cada tabla antes de combinarlas. Así, la base de datos solo une los datos que realmente importan, lo que reduce el uso de memoria, mejora la eficiencia del caché y mantiene predecible el plan de ejecución.

-- Joins every user, even inactive ones
SELECT e.*
FROM users u
JOIN events e ON e.user_id = u.id;

-- Filter first: only active, recently seen users
WITH active_users AS (
  SELECT id
  FROM users
  WHERE active = true
    AND last_seen > now() - interval '90 days'
)
SELECT e.*
FROM active_users u
JOIN events e ON e.user_id = u.id;

6. Prefiere EXISTS en lugar de IN para verificar relaciones

Cuando verificas si existen filas relacionadas, IN cumple su función… hasta que deja de hacerlo. Construye una lista completa de valores, compara cada uno y trata los NULL de una forma que puede ocultar coincidencias válidas.

EXISTS funciona diferente. Devuelve true en cuanto encuentra una coincidencia y no le afectan los NULL de la subconsulta. El resultado es más rápido y más confiable, sobre todo con conjuntos de datos grandes.

-- Works, but can be slower and NULL-prone
SELECT *
FROM users
WHERE id IN (SELECT user_id FROM orders);

-- Clear and efficient: stops at first match
SELECT *
FROM users u
WHERE EXISTS (
  SELECT 1
  FROM orders o
  WHERE o.user_id = u.id
);

7. Siempre especifica ORDER BY

SQL no garantiza el orden de las filas a menos que lo pidas.

Sin un ORDER BY, la base de datos puede devolver las filas en el orden que le resulte más conveniente, y eso puede cambiar entre ejecuciones, entornos o incluso actualizaciones menores.

Puede parecer estable en desarrollo, pero en cuanto cambian los índices, los planes de ejecución o el volumen de datos, empezarás a ver paginación impredecible o resultados inconsistentes en tu API.

-- Looks fine until it isn't
SELECT id, name
FROM users
WHERE active = true
LIMIT 10;

-- Predictable and reproducible
SELECT id, name
FROM users
WHERE active = true
ORDER BY created_at DESC
LIMIT 10;

Para cerrar

Las mejores consultas son las que entiendes un año después. Tienen una intención clara, un comportamiento predecible y ninguna sorpresa oculta.

Ese es el espíritu detrás de estos hábitos. Son prácticas que usamos todos los días en Beekeeper Studio para mantener las consultas legibles, consistentes y rápidas en todas las bases de datos con las que trabajamos.

Puedes descargar gratis una versión en PDF de esta guía para tenerla a la mano o compartirla con tu equipo:

Descarga 7 hábitos de SQL para desarrolladores ocupados

Con Beekeeper Studio puedes poner en práctica estos hábitos todos los días, usando un editor SQL moderno, multiplataforma y de código abierto, hecho para que no pierdas el ritmo.

• Más de 20 bases de datos compatibles: Postgres, MySQL, SQLite, SQL Server, MongoDB, Redis y más.
• Editor rápido y ágil: autocompletado que conoce tu esquema, consultas en pestañas y resaltado de sintaxis.
• Herramientas visuales de datos: explora tablas, edita filas e inspecciona JSON sin perder el contexto.
• Asistente de IA (privacidad primero): la herramienta de IA para programar que le faltaba a tu base de datos: conoce tu esquema, funciona con el LLM que elijas y te ayuda a explorar y afinar consultas más rápido.

Descarga Beekeeper Studio