Nivel 4 · Nuestros clientes más leales

WHERE filtra filas antes de agruparlas. HAVING filtra grupos después de la agregación. Esta consulta usa ambos:

SELECT customer_id, COUNT(*) AS completed_orders
FROM orders
WHERE status = 'completed'      -- which orders count
GROUP BY customer_id
HAVING COUNT(*) >= 30;          -- which customers qualify

Orden lógico de una consulta

La base de datos no ejecuta tus cláusulas en el orden en que las escribes. Lógicamente sigue:

1. FROM (y los joins)
2. WHERE, sobre filas individuales
3. GROUP BY
4. se calculan los agregados
5. HAVING, sobre grupos
6. SELECT, incluidos los alias
7. ORDER BY
8. LIMIT

Esto explica tres reglas a la vez:

• No puedes usar COUNT(*) en WHERE, porque los conteos todavía no existen en el paso 2.
• HAVING puede usar agregados, porque existen en el paso 5.
• Los alias de SELECT normalmente no son visibles en WHERE ni en HAVING, pero sí en ORDER BY. Postgres exige HAVING COUNT(*) >= 30, no HAVING completed_orders >= 30. DuckDB, MySQL y BigQuery aceptan el alias, así que repite el agregado si quieres SQL portable.

Pon las condiciones de fila en WHERE

Podrías escribir el filtro de status en HAVING con agregación condicional, pero una condición de fila simple pertenece a WHERE. Es más claro y elimina filas antes del costoso paso de agrupación. Una condición sobre una columna agrupada, como HAVING channel = 'app', funciona pero se escribe mejor como WHERE channel = 'app'. Usa HAVING solo para condiciones que necesiten un agregado.

WHERE cambia lo que ve HAVING

Estas dos preguntas suenan parecido y dan respuestas distintas:

• “Clientes con 30+ pedidos, contando solo los completados” (WHERE status, luego HAVING del conteo).
• “Clientes con 30+ pedidos de cualquier estado, mostrando su conteo de completados” (sin WHERE; la condición cuenta todos los pedidos, la columna cuenta solo los completados).

Lee el ticket dos veces y decide qué filtro se aplica antes o después de agrupar. Megan pidió el primero: los pedidos cancelados y reembolsados no cuentan para la lealtad.

Nota de entrevista

“¿Cuál es la diferencia entre WHERE y HAVING?” se pregunta en casi todas las entrevistas de analista. Una buena respuesta es una frase más una razón: WHERE filtra filas antes de agrupar, HAVING filtra grupos después de la agregación, porque los agregados no existen hasta el paso de agrupación. Mencionar que WHERE también es más barato, porque reduce los datos antes de agrupar, demuestra que piensas en el rendimiento.

Errores comunes

• Poner el conteo en WHERE. WHERE COUNT(*) >= 30 falla, porque los conteos todavía no existen cuando WHERE se ejecuta. Muévelo a HAVING COUNT(*) >= 30.
• Mover el filtro de status a HAVING. HAVING status = 'completed' falla porque status no está agrupado, y aunque se ejecute es la cláusula equivocada. Las condiciones de fila van en WHERE.
• Usar el alias en HAVING. HAVING completed_orders >= 30 funciona en DuckDB pero falla en Postgres y SQL Server. Repite el agregado.
• Usar > cuando el ticket dice “30 o más”. HAVING COUNT(*) > 30 descarta en silencio a todos los clientes con exactamente 30 pedidos.

En SQL Server

HAVING y el orden lógico son idénticos. SQL Server nunca acepta un alias de SELECT en HAVING, así que escribe HAVING COUNT(*) >= 30, no HAVING completed_orders >= 30, y usa TOP en lugar de LIMIT si recortas la lista.