Ya sabes formar grupos y calcular agregados sobre ellos. Falta la última pieza: filtrar los grupos. No "los pedidos de 2025", que es filtrar filas y eso ya lo hace WHERE, sino "los clientes que han hecho más de un pedido", "las categorías que facturan más de 150 €", "los productos que han vendido más de 8 unidades". Esas condiciones no se pueden evaluar mirando una fila: hay que haber formado el grupo y haber calculado su agregado antes de poder decidir.

Para eso existe HAVING. Su definición cabe en una línea —WHERE filtra filas, HAVING filtra grupos— y todo lo demás se deduce del diagrama del orden lógico que completaste ayer. En esta lección verás por qué HAVING puede usar agregados y WHERE no, por qué aun así WHERE es casi siempre preferible, cómo se combinan ambos en la misma consulta, y cerrarás el hilo que 03-03 dejó abierto con la tabla definitiva de los tres sitios donde se puede filtrar en SQL.

Y con esto se cierra el módulo 4.

1. HAVING en el orden lógico de ejecución
2. El primer HAVING: clientes con más de un pedido
3. Por qué HAVING puede usar agregados y WHERE no
4. La misma pregunta resuelta de las dos formas
5. Por qué WHERE es preferible: filtrar antes de agrupar
6. WHERE y HAVING en la misma consulta
7. HAVING sin GROUP BY
8. Varias condiciones en HAVING
9. HAVING sobre un agregado que no está en el SELECT
10. Casos de negocio de TiendaVerde
11. Los tres sitios donde se filtra: ON, WHERE y HAVING
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión del módulo

Recupera el diagrama de 04-05 y fíjate en el paso 4:

HAVING está después de GROUP BY y antes de SELECT. De esa única posición salen las cinco propiedades de la cláusula:

La sintaxis se coloca siempre entre GROUP BY y ORDER BY:

La pregunta clásica de fidelización: ¿qué clientes han repetido?

7 clientes de 15 han repetido. Sin el HAVING, la consulta devolvería 12 filas (los 12 compradores); con él, se quedan solo los grupos cuyo COUNT(*) supera 1. Se han descartado cinco grupos enteros: Marta, Tiago, Julien, Elena y Diego, cada uno con su único pedido.

Fíjate en que esta condición es imposible de escribir en el WHERE. Al evaluarse el WHERE, la consulta está mirando el pedido 1 de Lucía y no tiene forma de saber que existirán el 5 y el 15: los grupos aún no se han formado.

Intentémoslo, para ver el error:

El mensaje es tajante y el diagrama explica por qué. WHERE se ejecuta en el paso 2, cuando el motor está examinando una fila cada vez y no existe todavía ningún grupo. COUNT(*) no significaría nada ahí: ¿el recuento de qué?

HAVING se ejecuta en el paso 4, con los grupos ya construidos y sus agregados ya calculados. Puede preguntar por COUNT(*), SUM(...), AVG(...) o cualquier otro, porque son valores que ya existen.

Y lo simétrico: HAVING no puede usar una columna que no esté agrupada ni agregada, exactamente igual que el SELECT:

Es la regla de oro de 04-05, aplicada a HAVING. El grupo del cliente 5 contiene un pedido cancelado y otro pagado: ¿cuál es "el estado" de ese grupo? No hay respuesta. Si lo que querías era filtrar por estado, eso es un filtro de fila y va en el WHERE.

Y una tercera restricción, que ya viste en 04-05: HAVING no acepta alias del SELECT en PostgreSQL.

Hay que repetir el agregado: HAVING COUNT(*) > 1. Es redundante y es lo que exige el estándar, porque los alias nacen en el paso 5.

Cuando la condición recae sobre una columna del GROUP BY, sí se puede escribir en los dos sitios, y el resultado es idéntico. Es el mejor experimento para entender la diferencia.

La pregunta: "¿cuántos pedidos se pagaron con tarjeta?"

Versión A — filtrando filas con WHERE:

Versión B — filtrando grupos con HAVING:

Resultado idéntico. Las dos son válidas y metodo_pago es legal en el HAVING porque está en el GROUP BY. Pero no hacen el mismo trabajo:

La versión A agrupa 11 filas y forma 1 grupo. La versión B agrupa 20 filas, forma 4 grupos, calcula cuatro sumas y luego tira tres a la basura. Con 20 pedidos la diferencia es imperceptible; con veinte millones, es la diferencia entre una consulta instantánea y una que hace sudar al servidor.

La regla: si la condición se puede evaluar mirando una sola fila, va en el WHERE. Reserva HAVING para lo que exige haber calculado un agregado.

El principio se enunció en 02-03 y aquí alcanza su expresión más clara: filtrar pronto es filtrar barato. Cada fila descartada por el WHERE es una fila que no hay que ordenar, ni meter en una tabla hash, ni agregar.

Ese punto del índice es el más importante en tablas grandes. Un WHERE fecha_pedido >= '2025-01-01' puede resolverse con un índice sobre fecha_pedido, leyendo solo las filas relevantes. Un HAVING nunca puede: opera sobre valores que no existían hasta que la consulta los calculó.

Verlo requiere EXPLAIN, la herramienta que compara planes de ejecución, y eso es el módulo 8. Pero la intuición ya la tienes: en la versión A del apartado anterior, PostgreSQL puede descartar 9 de las 20 filas antes de tocar el GROUP BY; en la versión B, no puede descartar ninguna.

Consejo práctico: cuando escribas una consulta con GROUP BY, repasa cada condición del HAVING y pregúntate: "¿esto depende de más de una fila?". Si la respuesta es no, muévelo al WHERE. Es la optimización más barata que existe: no requiere índices, ni configuración, ni entender el planificador.

Lo habitual no es elegir entre uno y otro: es usar los dos, cada uno para lo suyo. WHERE acota el universo de filas, HAVING selecciona qué grupos merecen aparecer.

La pregunta: "de las ventas de 2025, ¿qué clientes gastaron más de 50 €?"

5 filas. El reparto de responsabilidades es perfectamente nítido:

Sin el HAVING el resultado tendría 12 filas; sin el WHERE, los totales incluirían 2026 y Sofia subiría de 64,88 € a 111,88 €, cambiando incluso el orden del ranking. Los dos filtros son necesarios y ninguno puede sustituir al otro.

Y observa un detalle de escritura: la expresión del importe está repetida en el SELECT y en el HAVING. Es obligatorio (el alias total_2025 no existe aún) y es feo. Las CTE del módulo 10 lo resolverán definitivamente.

HAVING puede aparecer sin GROUP BY. Cuando eso ocurre, SQL trata toda la tabla como un único grupo, exactamente igual que un agregado sin GROUP BY (04-04, sección 8). El resultado es una consulta que devuelve una fila o ninguna.

Como el catálogo tiene 20 productos y 20 > 5, el grupo único sobrevive y sale su fila. Ahora con una condición que no se cumple:

Cero filas. Es la única forma de que una consulta agregada sin GROUP BY no devuelva ninguna, y por eso desconcierta: sin HAVING, SELECT COUNT(*) FROM productos WHERE 1 = 0 devolvería una fila con un 0.

¿Para qué sirve? Casi para nada en el día a día. Su único uso razonable es como guardia de una comprobación: "devuélveme el resumen solo si hay datos suficientes", o "avísame solo si el total supera un umbral". Fuera de eso, un HAVING sin GROUP BY suele ser un WHERE mal escrito:

Regla práctica: si escribes HAVING y no hay GROUP BY en la consulta, párate y comprueba que era eso lo que querías. En nueve de cada diez casos, no lo era.

HAVING acepta condiciones compuestas con AND, OR, NOT y paréntesis, con la misma precedencia y las mismas trampas que el WHERE de 02-03. AND se evalúa antes que OR, y mezclarlos sin paréntesis produce resultados incorrectos sin dar ningún error.

La pregunta: "categorías con al menos 10 líneas de venta y más de 150 € facturados".

3 filas de 5. Se han descartado Hogar sostenible (7 líneas, no llega a 10) e Higiene personal (3 líneas y 31,50 €, falla las dos condiciones).

Y ahora la versión con OR, que responde a otra pregunta:

daría las mismas 3 filas en este conjunto de datos —las tres cumplen ambas condiciones—, lo cual es una coincidencia peligrosa: si mañana una categoría alcanzara 12 líneas con 90 € de facturación, AND la excluiría y OR la incluiría. Que dos consultas devuelvan lo mismo hoy no significa que sean equivalentes.

Recordatorio de 02-03: siempre que en un HAVING convivan AND y OR, pon paréntesis. La precedencia es la misma y el daño también.

Es perfectamente legal filtrar por un agregado que no muestras. También es una de las cosas que más confunden a quien lee la consulta después.

2 filas, y quien lea este resultado no puede saber por qué. Ni Cosmética natural (156,32 €) ni Hogar sostenible aparecen, pese a facturar más que muchas cosas. La razón está escondida en el HAVING: solo Alimentación (49 unidades) y Bebidas (29 unidades) superan las 25 unidades vendidas, y esa columna no se muestra.

Es legal, funciona y a veces es lo que quieres (un informe ejecutivo no tiene por qué enseñar los criterios de corte). Pero como norma de higiene:

Si filtras por un agregado, muéstralo. Añadir SUM(lp.cantidad) AS unidades al SELECT cuesta una línea y convierte un resultado misterioso en uno autoexplicativo. Tu yo de dentro de seis meses te lo agradecerá.

Cinco preguntas reales, resueltas.

4 categorías de 6. Quedan fuera Higiene personal (2 productos) y Complementos (1). Es el diagnóstico de un catálogo con dos áreas claramente infradesarrolladas.

6 productos de los 17 que se han vendido alguna vez. Son los de mayor rotación, y el equipo de compras debería vigilar su stock con prioridad.

3 categorías concentran 607,87 € de los 727,95 € facturados, un 83,5 %. Es la regla de Pareto asomando en un conjunto de datos de veinte pedidos.

2 filas. Aquí conviene recordar el aviso de 04-05: esta consulta usa INNER JOIN, así que los 10 pedidos del canal web no están y los cinco empleados sin pedidos tampoco. Para este informe concreto da igual —preguntamos por quien gestiona más de tres, y quien gestiona cero no es candidato—, pero si la pregunta fuera "reparto de la carga comercial", faltaría la mitad de la empresa.

Esta es la que no se puede resolver todavía, y merece la pena entender exactamente por qué.

Empecemos por lo que sí sabemos calcular. El ticket medio de cada cliente:

Y también sabemos calcular la media general de los 20 tickets, en otra consulta: 36,40 €.

Lo que no podemos hacer es escribir HAVING ... > (la media general) dentro de la misma consulta, porque ese valor es a su vez un agregado calculado sobre otro conjunto de filas. HAVING puede comparar el agregado de un grupo con una constante (> 50) o con otro agregado del mismo grupo (SUM(a) > SUM(b)), pero no con un agregado global.

La solución es una subconsulta que calcule la media general y la inyecte en el HAVING, y eso es la lección 07-01. Allí escribirás algo con esta forma:

Cuando llegues, sabrás que la respuesta son tres clientes —Julien Moreau, Sofia Moreira Costa y Tiago Almeida Nunes—, los únicos que superan los 36,40 € de ticket medio general. De momento, la forma honesta de resolverlo es en dos consultas y comparando a mano; saber cuándo una pregunta necesita una herramienta que aún no tienes es tan importante como saber usar las que ya tienes.

Aquí se cierra el hilo que 03-03 dejó abierto. SQL tiene tres lugares donde poner una condición, y cada uno actúa en un momento distinto del orden lógico:

Y la comprobación final con los tres a la vez, en una única consulta de TiendaVerde:

2 filas, y las tres cláusulas han hecho un trabajo distinto e insustituible:

• El ON ha restringido el emparejamiento a los pedidos entregados, sin eliminar a los clientes que no tienen ninguno (si esa condición hubiera ido al WHERE, el LEFT JOIN se habría degradado a INNER, tal como demostró 03-03).
• El WHERE ha filtrado por una columna de la tabla izquierda, que es seguro y no degrada nada: quedan los 11 clientes españoles.
• El HAVING ha descartado los 9 clientes españoles con menos de dos pedidos entregados — entre ellos Ana Belmonte Roca, que tiene dos pedidos pero ninguno entregado, y Núria, Hugo e Inés, que aparecían con un honesto 0 gracias al LEFT JOIN y a COUNT(pe.id).

Toda la lógica de filtrado del curso, en once líneas.

• Poner un agregado en el WHERE. ERROR: aggregate functions are not allowed in WHERE. Va en HAVING.
• Poner en el HAVING una condición que se puede evaluar fila a fila. Funciona, pero agrupa filas que iban a tirarse. Muévelo al WHERE.
• Usar en HAVING una columna que no está en el GROUP BY. column ... must appear in the GROUP BY clause. Si es un filtro de fila, va en el WHERE.
• Usar un alias del SELECT en el HAVING. column "..." does not exist en PostgreSQL, aunque MySQL y SQLite lo permitan. Repite el agregado.
• Escribir HAVING sin GROUP BY por error. Trata toda la tabla como un grupo y devuelve una fila o ninguna. Casi siempre querías un WHERE.
• Mezclar AND y OR en el HAVING sin paréntesis. Misma precedencia y mismo daño silencioso que en el WHERE (02-03).
• Filtrar por un agregado que no muestras. Es legal y deja un resultado incomprensible. Añádelo al SELECT.
• Olvidar que un INNER JOIN en la consulta ya ha descartado grupos. El HAVING filtra lo que le llega; si el JOIN perdió filas antes, el informe ya estaba incompleto (04-05, sección 10).
• Intentar comparar el agregado de un grupo con un agregado global. Necesita subconsulta: 07-01.
• Consejo: escribe la consulta por capas. Primero el FROM con sus JOIN y cuenta filas; luego el WHERE; luego el GROUP BY y comprueba el número de grupos; y solo al final el HAVING. Depurar una consulta agregada escrita de una tacada es un suplicio.
• Consejo: comprueba cuántos grupos descarta el HAVING. Ejecuta la consulta sin él y compara: 12 clientes contra 7, 5 categorías contra 3. Ese delta te confirma que la condición hace lo que crees.
• Consejo: lee la pregunta de negocio buscando el sujeto. "Clientes que hayan hecho más de un pedido" → el sujeto es el cliente y la condición es sobre su conjunto de pedidos: GROUP BY cliente + HAVING. "Pedidos de más de 50 €" → el sujeto es el pedido: puede que sea WHERE.

Compras quiere identificar proveedores con catálogo relevante. Escribe una consulta que devuelva, para cada proveedor con al menos 4 productos en catálogo: su nombre, su país, el número de productos, el precio medio (dos decimales) y el precio del producto más caro.

Ordena por número de productos descendente. Después responde: ¿qué proveedor queda fuera y por qué?

Dirección quiere saber en qué meses de 2025 se superaron los 60 € de facturación. Escribe una única consulta que use WHERE y HAVING, mostrando el mes (AAAA-MM), el número de pedidos distintos, el de líneas y la facturación.

Después indica, para cada una de las tres cláusulas de filtrado, qué condición le corresponde y por qué no podría ir en las otras.

Un compañero te pasa esta consulta con el comentario "quiero las categorías con más de 20 unidades vendidas, pero me faltan categorías y no sé si el número está bien":

1. ¿Qué categorías devuelve y qué categorías "faltan"? ¿Es un error del HAVING?
2. La columna portes está mal. Explica por qué y calcula cuánto vale realmente para Alimentación frente a lo que debería valer.
3. Reescribe la consulta corrigiendo lo que se pueda corregir hoy e indica qué parte necesita el módulo 7.

Solución 1

4 filas. Queda fuera BioSierra Ibérica, que solo suministra 3 productos (la miel, la pasta de espelta y la infusión de manzanilla) y no llega al umbral de 4. Comprobación: 5 + 4 + 4 + 4 + 3 = 20 productos.

Dos observaciones sobre estos precios medios, que ahora sí son los de catálogo: son distintos de los que salían en la solución 2 de 04-05 (6,73 € para Huerta del Turia en lugar de 5,74 €). La diferencia es que aquí partimos de productos y cada referencia cuenta una vez; allí partíamos de un LEFT JOIN con lineas_pedido y cada referencia contaba tantas veces como se hubiera vendido. Las dos medias son correctas y responden a preguntas distintas: "precio medio del catálogo" frente a "precio medio de lo que se vende". Comprobar de qué tabla parte una consulta antes de interpretar su media es un hábito que evita muchos disgustos.

Y fíjate en que EcoNordic Supplies aparece pese a estar inactivo: la consulta no filtra por pr.activo. Si la pregunta fuera "proveedores operativos con catálogo relevante", habría que añadir WHERE pr.activo — un filtro de fila, no de grupo.

Solución 2

5 meses de los 10 de 2025 superaron los 60 €. Y aparece un patrón interesante: los cinco son meses con 2 pedidos y 5 líneas. Con este volumen, facturar bien un mes es simplemente que caigan dos pedidos en lugar de uno.

Reparto de responsabilidades:

La condición del WHERE no podría ir en el HAVING: pe.fecha_pedido no está en el GROUP BY (agrupamos por mes, no por día), así que daría el error must appear in the GROUP BY clause. Y la del HAVING no podría ir en el WHERE: aggregate functions are not allowed in WHERE. Cada una solo cabe donde está.

Solución 3

1. Qué devuelve y qué falta.

2 filas. Las categorías que "faltan" son:

• Cosmética natural (16 unidades), Hogar sostenible (10) e Higiene personal (9): no faltan por error, es el HAVING haciendo su trabajo. Ninguna supera las 20 unidades. Correcto.
• Complementos (0 unidades): esta sí falta por un motivo distinto. No la descarta el HAVING, la descartó el INNER JOIN mucho antes, en el paso 1. Es el problema de 04-05 sección 10. Ahora bien: como su condición sería 0 > 20, tampoco habría aparecido con LEFT JOIN. El resultado es el mismo, pero por razones distintas, y esa distinción importa — con el umbral en > 20 da igual, con el umbral en >= 0 no daría igual en absoluto.

2. Por qué portes está mal. gastos_envio vive en pedidos, y tras el JOIN con lineas_pedido cada pedido aparece tantas veces como líneas tenga. Es el error de 04-04 sección 11, ahora dentro de un GROUP BY.

Para Alimentación, la consulta da 86,75 €; para Bebidas, 90,10 €. Sumadas todas las categorías darían 278,70 €, el mismo número inflado de 04-04 sección 11, frente a los 118,25 € reales.

¿Y qué debería dar? La pregunta ni siquiera está bien planteada: los gastos de envío no se pueden repartir por categoría, porque un pedido con productos de tres categorías paga unos portes, no tres. Los 4,95 € del pedido 1 no son "4,95 € de Alimentación": son 4,95 € del pedido, y el pedido 1 lleva productos de Alimentación y de Bebidas.

Ese es el punto más profundo del ejercicio. El número está mal, pero el problema real es que la métrica no existe al nivel de granularidad que se pide. Es exactamente el tipo de pregunta que hay que devolver a quien la formula.

3. La versión corregida:

Cambios aplicados:

Qué necesita el módulo 7. Si la pregunta fuera "¿cuánto de los portes es atribuible a cada categoría, prorrateado por el peso de cada categoría en el importe del pedido?", eso es una métrica legítima pero exige calcular primero el total de cada pedido, luego el peso de cada línea sobre ese total, y después repartir. Ese "calcular un agregado y usarlo en otro cálculo" es precisamente lo que resuelven las subconsultas del módulo 7 y las CTE del módulo 10.

HAVING cierra la lógica de filtrado de SQL:

• WHERE filtra filas, HAVING filtra grupos. Todo lo demás se deduce de su posición en el orden lógico: FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT.
• HAVING puede usar agregados y WHERE no, porque cuando se ejecuta el WHERE los grupos aún no existen. Y HAVING no puede usar columnas no agrupadas, por la misma regla de oro que el SELECT.
• Cuando la condición recae sobre una columna del GROUP BY, las dos escrituras dan el mismo resultado pero no el mismo trabajo: WHERE agrupa 11 filas, HAVING agrupa 20 y tira 3 grupos. Filtrar antes de agrupar es siempre preferible, y además es lo único que puede aprovechar un índice (EXPLAIN, módulo 8).
• Lo normal es usar los dos a la vez: WHERE acota el universo (2025) y HAVING selecciona los grupos que importan (más de 50 €).
• HAVING sin GROUP BY trata la tabla entera como un grupo y devuelve una fila o ninguna. Casi siempre es un WHERE mal escrito.
• Los tres sitios donde se filtra son ON (condiciona el emparejamiento y conserva las filas izquierdas de un LEFT JOIN), WHERE (filtra filas y degrada el LEFT a INNER si toca la tabla derecha) y HAVING (filtra grupos). El hilo abierto en 03-03 queda cerrado.
• Has resuelto los casos de negocio reales de TiendaVerde: 7 clientes recurrentes, 4 categorías con más de 3 productos, 6 productos con más de 8 unidades vendidas, 3 categorías que concentran el 83,5 % de la facturación. Y sabes qué preguntas todavía no puedes responder: comparar el agregado de un grupo con un agregado global exige subconsultas (07-01).

Y con esto se cierra el módulo 4. Repasa lo que has ganado en seis lecciones: buscas por patrones de texto con LIKE, ILIKE y expresiones regulares, y sabes cuál de ellos puede usar un índice; filtras por listas y rangos con IN y BETWEEN, y conoces el error más caro de SQL —NOT IN con un NULL—; entiendes la lógica de tres valores y con ella se te han resuelto de golpe cinco misterios que arrastrabas desde el módulo 2; calculas con COUNT, SUM, AVG, MIN y MAX, y sabes que todas ignoran los nulos menos COUNT(*); partes los datos en grupos con GROUP BY combinado con JOIN, que es el patrón central de todo el análisis de datos; y filtras esos grupos con HAVING. De propina, has liquidado el aviso que el módulo 3 te repitió tres veces: 278,70 € frente a 118,25 €, y sabes exactamente por qué.

Hasta aquí, sin embargo, solo has leído. Las cuatro instrucciones que has usado —SELECT, FROM, WHERE, GROUP BY— pertenecen todas al mismo sublenguaje, el DQL del que hablaba 01-01, y ninguna de ellas ha cambiado jamás un solo byte de TiendaVerde. Podrías haber trabajado todo el curso sobre una base de datos de solo lectura y no habrías notado la diferencia.

Pero una tienda que no puede dar de alta un producto, registrar un pedido, corregir un precio ni cancelar una compra no es una tienda: es un catálogo muerto. En el módulo 5, Manipulación de datos, cruzarás al otro lado. Aprenderás a crear tablas con CREATE TABLE —con los tipos, las claves y las restricciones que llevas cinco módulos leyendo en el esquema de TiendaVerde—, a insertar filas con INSERT, a modificarlas con UPDATE, a eliminarlas con DELETE, a resolver el clásico "insértalo si no existe y actualízalo si existe" con UPSERT, y a cambiar la estructura de una tabla en producción con ALTER TABLE. Cambia también el nivel de responsabilidad: un SELECT mal escrito devuelve un número equivocado, pero un UPDATE sin WHERE modifica las veinte filas de la tabla y no hay forma de deshacerlo. Ese WHERE que llevas cuatro módulos afinando deja de ser una cuestión de precisión analítica y pasa a ser tu red de seguridad.