Agregación y agrupación en SQL

Una función de agregación combina valores de muchas filas en un resultado. Oracle también la llama función de grupo. Sin GROUP BY, una consulta de agregación trata todas las filas que pasan WHERE como un grupo y devuelve una fila de resumen.

Empieza con datos que puedas comprobar

Cada fila de orders es un pedido. Las columnas numéricas siguientes contienen números enteros; order_id es la clave primaria. Las fechas utilizan texto ISO en SQLite y el tipo DATE en PostgreSQL.

Elige la medida

SUM(amount) suma los importes. AVG(amount) da su media aritmética. MIN(amount) encuentra el importe mínimo y MAX(amount) encuentra el máximo. Puedes solicitar las cuatro en una consulta:

SELECT SUM(amount) AS total, AVG(amount) AS avg_amount, MIN(amount) AS smallest, MAX(amount) AS largest FROM orders;

El resultado es una fila: total 780, promedio 97,5, mínimo 30 y máximo 200. Suma los ocho importes para obtener 780 y después divide entre ocho para obtener 97,5. Cada función utiliza las mismas ocho filas de entrada. Los alias claros después de AS hacen que los encabezados de salida sean útiles; un encabezado generado como sum dice poco sobre lo que se ha sumado.

Filtra antes de calcular

Para resumir los pedidos de East, escribe SELECT COUNT(*) AS orders, SUM(amount) AS total FROM orders WHERE region = 'East';. El filtro conserva los importes 120, 45 y 95. La consulta devuelve tres pedidos y un total de 260. WHERE elige las filas de entrada antes de ejecutar cualquier función de agregación.

Una función de agregación también puede recibir una expresión calculada. En una tabla con quantity y unit_price, SUM(quantity * unit_price) primero calcula los ingresos de cada fila y después los suma. Dos filas, dos artículos a 5 y tres artículos a 10, aportan 10 y 30, para un total de 40. En cambio, SUM(quantity) * SUM(unit_price) multiplica 5 por 15 y da 75. Mantener el cálculo dentro de SUM conserva la correspondencia entre cada cantidad y su precio.

Interpreta correctamente los valores extremos

MIN(order_date) es 2026-01-05 y MAX(order_date) es 2026-03-21. Los valores de fecha y el texto de fecha ISO se ordenan cronológicamente. Un texto como «03/21/2026» sigue el orden de los caracteres, que no coincide de forma fiable con el orden de las fechas. Los valores extremos de texto también siguen la intercalación de la base de datos, sus reglas para comparar texto. Aquí los clientes extremos son «Ana» y «Eli»; mezclar mayúsculas y minúsculas puede cambiar la ordenación del texto.

MAX(amount) devuelve un importe, no el pedido completo que lo contiene. Para mostrar un cliente con un pedido de importe máximo, utiliza SELECT customer, amount FROM orders ORDER BY amount DESC LIMIT 1;. PostgreSQL rechaza una columna customer sin agregar junto a MAX(amount) sin una agrupación adecuada. SQLite tiene una regla especial para un único MIN o MAX que puede devolver una columna contigua de la fila extrema, pero los extremos empatados siguen necesitando una regla de desempate.

«¿Cuántos?» puede preguntar por filas, valores registrados o valores diferentes. Son recuentos distintos, aunque en una tabla pequeña puedan dar por casualidad el mismo número.

Tres formas de COUNT

En la tabla de pedidos, las regiones son East, West, East, North, West, East, North y NULL. SELECT COUNT(*) AS order_rows, COUNT(region) AS with_region, COUNT(DISTINCT region) AS regions FROM orders; devuelve 8, 7 y 3. Los nombres de región repetidos se cuentan por separado en COUNT(region), pero cada nombre contribuye solo una vez al recuento de valores distintos.

Para «¿Cuántos clientes diferentes hicieron pedidos?», utiliza COUNT(DISTINCT customer). Ana, Ben y Chen aparecen dos veces cada uno, mientras que Dara y Eli aparecen una vez, por lo que la respuesta es cinco clientes. COUNT(customer) devuelve ocho porque todos los pedidos indican un cliente. Mide filas de pedido que indican un cliente, no personas.

Un cero registrado también cuenta

Los descuentos son 10, NULL, 5, NULL, 0, NULL, 15 y NULL. COUNT(discount) devuelve cuatro. El cero registra un valor conocido y cuenta igual que 10, 5 y 15. Una cadena vacía también es un valor en SQLite y PostgreSQL; Oracle trata una cadena vacía como NULL.

Resta el recuento de valores que no son NULL del recuento de filas para medir los registros sin ese dato: SELECT COUNT(*) - COUNT(region) AS missing_region FROM orders; devuelve uno. Esto funciona porque ambos recuentos utilizan exactamente las mismas filas de entrada.

Listas de valores distintos y recuentos de valores distintos

SELECT DISTINCT region FROM orders; enumera East, West, North y una fila NULL. Su función es devolver valores diferentes, y NULL permanece en esa lista. COUNT(DISTINCT region) devuelve tres porque el recuento ignora NULL. No deduzcas un recuento de valores distintos contando una lista sin haber decidido si debe incluir su fila NULL.

DISTINCT también puede aparecer dentro de SUM o AVG. Las cantidades son 2, 1, 3, 4, 1, 2, 5 y 1. Su suma normal es 19. SUM(DISTINCT quantity) conserva solo 1, 2, 3, 4 y 5, lo que da 15. Las cantidades repetidas suelen describir ventas adicionales reales. Eliminarlas cambia la medida; no corrige registros duplicados.

Cuenta combinaciones en dos pasos

Para obtener pares diferentes de región y cliente, crea primero una lista sin duplicados:

SELECT COUNT(*) FROM (SELECT DISTINCT region, customer FROM orders) AS pairs;

La consulta interna devuelve cinco pares: East/Ana, East/Dara, North/Chen, West/Ben y NULL/Eli. El COUNT(*) externo cuenta esas cinco filas, incluida NULL/Eli. Esta forma funciona en SQLite y PostgreSQL. MySQL también acepta COUNT(DISTINCT region, customer), pero esa forma excluye las combinaciones que contienen NULL, por lo que puede responder otra pregunta. En SQLite y PostgreSQL, la forma separada por comas no es válida.

Por último, un recuento nunca devuelve NULL. SELECT COUNT(*) FROM orders WHERE region = 'South'; devuelve una fila de resumen que contiene cero, porque no hay pedidos que coincidan.

NULL significa que un valor está ausente o es desconocido. Cambia los valores que recibe una función de agregación, por lo que un total o promedio puede ser válido en SQL y, aun así, medir algo diferente de lo que pretendías.

Determina el denominador

Supón que scores contiene Ana 80, Ben NULL, Chen 70 y Dara 90. SUM(score) es 240, COUNT(score) es tres y COUNT(*) es cuatro. AVG(score) es 80: las tres calificaciones registradas suman 240 y se dividen entre tres.

Las cinco funciones de agregación estándar ignoran los argumentos NULL. COUNT(*) cuenta todas las filas porque no evalúa un argumento de columna. MIN(score) es 70 y MAX(score) es 90; NULL no se convierte en la calificación mínima ni en la máxima. Esto difiere de la ordenación, en la que los valores NULL ocupan un extremo del resultado: al principio en una ordenación ascendente de SQLite y al final en una ordenación ascendente de PostgreSQL.

Un promedio calculado manualmente necesita el recuento de valores que no son NULL: 1.0 * SUM(score) / NULLIF(COUNT(score), 0). El operando decimal conserva los resultados fraccionarios, y NULLIF convierte en NULL un divisor cero. Dividir entre COUNT(*) daría 60 y, en la práctica, trataría la calificación ausente como cero.

Decide qué significa un valor predeterminado

COALESCE devuelve el primer argumento que no es NULL. Si Ben aún no ha sido calificado, deja su calificación ausente y calcula el promedio de los resultados conocidos. Si la ausencia a un examen se registra como NULL pero debe contar como cero, AVG(COALESCE(score, 0)) calcula el promedio de 80, 0, 70 y 90, que da 60. El significado de los datos determina si esa sustitución está justificada.

Compara colocar COALESCE dentro y fuera de una función. AVG(COALESCE(score, 0)) cambia los valores que entran en el promedio. COALESCE(AVG(score), 0) cambia solo un resultado final NULL; sigue dando 80 para estas calificaciones. NVL(x, 0) de Oracle es otra forma con dos argumentos para sustituir NULL.

Distingue entre ausencia de filas y ausencia de valores registrados

Con WHERE region = 'South', no queda ningún pedido. Una consulta de agregación sin GROUP BY sigue devolviendo una fila: COUNT(*) es cero, mientras que SUM(amount), AVG(amount), MIN(amount) y MAX(amount) son NULL. Para mostrar un total vacío como cero, utiliza COALESCE(SUM(amount), 0). SQLite también ofrece TOTAL(amount), que devuelve 0,0 para un conjunto de entrada vacío.

Ahora conserva los cuatro pedidos cuyo descuento es NULL. Hay filas, pero no hay valores de descuento registrados: COUNT(*) es cuatro, COUNT(discount) es cero y SUM(discount) es NULL. Cero valores registrados y cuatro valores ausentes son observaciones diferentes.

Comprueba las expresiones antes de que entren en SUM

Las operaciones aritméticas con NULL producen NULL. En SUM(amount - discount), los cuatro pedidos sin un descuento registrado no aportan ningún valor. Solo contribuyen las filas con descuento conocido: 110, 40, 60 y 135, que suman 345.

Si un descuento ausente significa que no hay descuento, escribe SUM(amount - COALESCE(discount, 0)). Así contribuyen todos los pedidos; el importe total de 780 menos los descuentos registrados de 30 da 750. Envolver toda la suma en COALESCE no recuperaría los pedidos omitidos, porque 345 ya es un valor que no es NULL.

Para localizar valores ausentes, utiliza IS NULL o IS NOT NULL. WHERE discount IS NULL encuentra cuatro pedidos. discount = NULL nunca es verdadero y, por tanto, no puede seleccionarlos.

GROUP BY reúne filas que comparten un valor de agrupación. Cada función de agregación se ejecuta por separado dentro de cada grupo, y la salida contiene una fila por cada grupo que existe después del filtrado.

Decide qué significa una fila del resultado

«Ventas totales por región» pide una fila de salida por región. Empieza escribiendo esa frase y después utiliza region como columna de agrupación:

SELECT region, COUNT(*) AS orders, SUM(amount) AS total FROM orders GROUP BY region;

Los tres importes de East, 120, 45 y 95, forman un grupo. Su recuento es tres y su total es 260. North tiene dos pedidos que suman 350; West tiene dos que suman 140. El pedido de Eli forma un grupo de región NULL con un pedido que suma 30. Hay cuatro filas de resultado, no ocho.

Lee la consulta como una secuencia: FROM aporta pedidos, cualquier WHERE elimina filas, GROUP BY reúne las filas restantes por región y las funciones de agregación resumen cada conjunto. SELECT muestra su etiqueta y sus medidas. La agrupación no descarta los pedidos menores dentro de un grupo; todos contribuyen salvo que un filtro de filas los haya eliminado.

Mantén visibles las categorías ausentes

Las filas con NULL en la columna de agrupación pertenecen a un grupo NULL. Esto es útil: un informe puede mostrar cuánta actividad no tiene una región registrada. No trata cada región ausente como una categoría diferente.

Para mostrar una etiqueta legible, selecciona COALESCE(region, 'No region') AS region_label y conserva GROUP BY region. La etiqueta cambia el valor mostrado. Para excluir esas filas de los cálculos, añade WHERE region IS NOT NULL antes de GROUP BY. Los totales resultantes suman 750, porque se ha excluido el importe de 30 de Eli.

Una consulta agrupada sobre un conjunto de entrada sin filas no devuelve grupos. Por ejemplo, filtrar la tabla para South y después agrupar por región no devuelve filas de resultado. Eso difiere de una agregación de toda la tabla sin GROUP BY, que produce una fila de resumen incluso con un conjunto de entrada vacío.

Ordena los grupos de forma explícita

GROUP BY no garantiza ningún orden de salida. Para enumerar primero las regiones con los mayores totales, añade ORDER BY total DESC. El alias total está permitido en ORDER BY; ORDER BY SUM(amount) DESC da la misma ordenación.

Un informe de clientes puede seleccionar los tres totales más altos:

SELECT customer, SUM(amount) AS total FROM orders GROUP BY customer ORDER BY total DESC, customer LIMIT 3;

Devuelve Chen 350, Ana 165 y Ben 140. La segunda clave de ordenación, customer, da a los totales empatados un orden reproducible. LIMIT 3 devuelve solo tres filas; no conserva todos los empates en el límite. SQL Server expresa este límite con SELECT TOP 3, mientras que Oracle admite FETCH FIRST 3 ROWS ONLY.

Al ordenar las etiquetas de categoría de forma ascendente, SQLite normalmente coloca NULL al principio y PostgreSQL lo coloca al final. Especifica la ordenación deseada cuando la posición sea relevante.

Comprueba la columna de agrupación

SELECT DISTINCT region FROM orders y SELECT region FROM orders GROUP BY region devuelven las mismas etiquetas de región distintas, incluido NULL. Utiliza la agrupación cuando también necesites una medida para cada etiqueta.

Agrupar por el valor único order_id da ocho grupos de una fila cada uno. Todos los recuentos son uno, y cada total de importes equivale al importe original. Para un informe regional, ese resultado indica que la columna de agrupación es demasiado detallada.

Un informe agrupado tiene que reunir muchas filas de entrada en una fila de resultado. Por tanto, cada valor mostrado necesita un significado claro para todo el grupo. Por eso SQL restringe las columnas que puedes seleccionar.

Sigue la regla de agrupación compatible con distintas bases de datos

Un elemento de un SELECT agrupado debe ser una columna de agrupación, una expresión construida a partir de columnas de agrupación, una función de agregación o una constante. Considera:

SELECT region, customer, COUNT(*) FROM orders GROUP BY region;

East contiene Ana, Ana y Dara. El grupo tiene una región y un recuento, pero dos nombres de cliente diferentes. La consulta no ha indicado qué cliente debe mostrar el único resultado de East. PostgreSQL rechaza la columna customer sin agrupar.

El mismo problema aparece sin GROUP BY: SELECT customer, SUM(amount) FROM orders combina un total de toda la tabla con un nombre individual. El total no tiene una única etiqueta de cliente.

Corrige la consulta para que responda la pregunta

Hay tres correcciones útiles, cada una con un significado diferente:

• Para obtener una fila por región, elimina customer: SELECT region, COUNT(*) FROM orders GROUP BY region;.
• Para obtener una fila por región y cliente, agrupa por ambos: SELECT region, customer, COUNT(*) FROM orders GROUP BY region, customer;.
• Para obtener el número de clientes por región, aplica una función de agregación a los nombres: SELECT region, COUNT(DISTINCT customer) AS customers FROM orders GROUP BY region;.

La última consulta muestra dos clientes en East y uno en cada uno de los demás grupos de región. Añadir una columna a GROUP BY puede cambiar el nivel de detalle del informe, así que elige la corrección según la pregunta, no solo según el mensaje de error.

Una columna de agrupación puede omitirse de SELECT. SELECT COUNT(*) FROM orders GROUP BY region; es válida y devuelve cuatro recuentos: tres, dos, dos y uno, sin un orden garantizado. Es difícil utilizar esas cifras sin sus etiquetas de región.

Aplica la regla más allá de SELECT

Un ORDER BY customer agrupado presenta el mismo problema al agrupar solo por región: ¿qué cliente debe determinar la posición de East? Las condiciones HAVING de una consulta agrupada también deben describir un grupo completo. Utiliza en ellas columnas agrupadas o expresiones de agregación.

Reconoce el comportamiento permisivo de algunas bases de datos

SQLite acepta una columna sin agrupar ni agregar, una columna seleccionada que no está agrupada ni se utiliza en una función de agregación. Toma un valor de una fila de entrada del grupo. Un resultado aparentemente correcto, como «Ana» junto a East, no significa que Ana represente todos los pedidos de esa región.

Con exactamente una función de agregación incorporada MIN o MAX, SQLite toma los valores sin agrupar ni agregar de una fila que contiene el extremo. Los empates y la presencia de varias funciones de extremos hacen incierta la fila seleccionada. Este atajo es específico de esa base de datos. Ordenar las filas originales es más claro cuando quieres un pedido con un importe extremo.

El modo predeterminado ONLY_FULL_GROUP_BY de MySQL rechaza los valores sin agrupar que el grupo no determina. ANY_VALUE(customer) permite explícitamente un valor arbitrario, pero no encuentra el cliente asociado a un total elegido. SQL Server y Oracle también rechazan las columnas ordinarias sin agrupar.

PostgreSQL y MySQL reconocen una excepción para la clave primaria: agrupar por la clave primaria de una tabla identifica una sola fila, por lo que sus demás columnas quedan determinadas. SELECT order_id, customer, SUM(amount) FROM orders GROUP BY order_id funciona en PostgreSQL. Incluir en GROUP BY todas las columnas mostradas sin agregar sigue siendo el enfoque compatible con distintas bases de datos.

Algunos informes necesitan una combinación de categorías o una categoría calculada a partir de cada fila. SQL puede agrupar por varias columnas o por una expresión. La decisión importante sigue siendo qué representa una fila de salida.

Agrupa por una combinación

GROUP BY region, customer reúne filas solo cuando coinciden ambos valores. En la tabla de pedidos, ejecuta:

SELECT region, customer, COUNT(*) AS orders, SUM(amount) AS total FROM orders GROUP BY region, customer ORDER BY region, customer;

Los resultados son East/Ana: dos pedidos, 165; East/Dara: uno, 95; North/Chen: dos, 350; West/Ben: dos, 140; y NULL/Eli: uno, 30. Los dos resultados de East suman el total regional de 260.

Agrupar por customer, region forma las mismas combinaciones. El orden de las columnas en GROUP BY no ordena la salida. El ORDER BY separado de arriba elige cómo mostrarla, según la posición predeterminada de NULL en cada base de datos.

Solo aparecen las combinaciones presentes en los datos de entrada. No hay una fila West/Ana con un recuento de cero. La agrupación resume filas existentes; no genera todos los emparejamientos posibles de etiquetas de categoría.

Añade detalle solo cuando sea necesario

Añadir una columna divide un grupo solo si sus filas contienen valores diferentes en esa columna. Aquí, agrupar solo por cliente ya da cinco grupos. Añadir la región sigue dando cinco, porque cada cliente tiene un solo valor de región. Añadir order_date a un informe regional crea grupos menores para las distintas fechas y cambia la pregunta que se responde.

Agrupa fechas por año y mes

En SQLite, utiliza strftime('%Y-%m', order_date) para crear una etiqueta como «2026-02»:

SELECT strftime('%Y-%m', order_date) AS month, COUNT(*) AS orders, SUM(amount) AS total FROM orders GROUP BY strftime('%Y-%m', order_date) ORDER BY month;

Enero tiene dos pedidos que suman 200, febrero tiene tres que suman 305 y marzo tiene tres que suman 275. En PostgreSQL, sustituye las dos apariciones de strftime('%Y-%m', order_date) por to_char(order_date, 'YYYY-MM') para una columna DATE.

Agrupar solo por el número de mes combina el mismo mes de distintos años. Enero de 2025 y enero de 2026 se convertirían en un grupo. Mantener el año en la expresión de agrupación conserva separados los meses de cada año.

Repetir la expresión en GROUP BY hace explícita la agrupación. SQLite, PostgreSQL y MySQL también aceptan el alias de salida, como GROUP BY month; SQL Server no acepta ahí un alias de SELECT del mismo nivel.

Crea categorías con CASE

Una expresión CASE puede asignar una etiqueta a cada pedido antes de agrupar:

SELECT CASE WHEN amount >= 100 THEN 'large' ELSE 'small' END AS size, COUNT(*) AS orders, SUM(amount) AS total FROM orders GROUP BY CASE WHEN amount >= 100 THEN 'large' ELSE 'small' END;

La categoría large contiene 120, 200 y 150: tres pedidos que suman 470. La categoría small contiene cinco pedidos que suman 310. El umbral es inclusivo, por lo que un importe de exactamente 100 pertenece a «large». La misma expresión CASE aparece en la presentación y en la agrupación para que ambas utilicen la misma definición de categoría.

HAVING comprueba los grupos después de calcular sus funciones de agregación. Utilízalo para una petición como «regiones con ventas totales superiores a 200». La condición describe cada total regional, no un pedido individual.

Primero calcula, después conserva los grupos

SELECT region, COUNT(*) AS orders, SUM(amount) AS total FROM orders GROUP BY region HAVING SUM(amount) > 200;

Antes de HAVING, los totales regionales son East 260, North 350, West 140 y NULL 30. La condición conserva East con tres pedidos y North con dos. Elimina los otros dos grupos del resultado; no elimina pedidos concretos del interior de East o North.

En SQL escrito, coloca HAVING después de GROUP BY y antes de ORDER BY. La ordenación se aplica después a los grupos que han superado la condición.

Filtra por medidas que no muestras

SELECT region FROM orders GROUP BY region HAVING COUNT(*) >= 2; devuelve East, North y West. La base de datos puede contar las filas de un grupo para decidir si cumple la condición sin mostrar ese recuento. HAVING y SELECT no necesitan listas de funciones de agregación idénticas.

Puedes combinar condiciones de grupo. HAVING COUNT(*) >= 2 AND AVG(amount) > 80 conserva East y North. East tiene tres pedidos y un promedio aproximado de 86,67; North tiene dos y un promedio de 175. West tiene suficientes pedidos, pero su promedio es solo 70. Deben cumplirse ambas condiciones porque están unidas con AND; OR permitiría que se cumpliera cualquiera de las dos.

Encuentra valores repetidos

Agrupar y contar también permite encontrar duplicados:

SELECT customer, COUNT(*) AS orders FROM orders GROUP BY customer HAVING COUNT(*) > 1;

Ana, Ben y Chen tienen dos pedidos cada uno y cumplen la condición. Dara y Eli tienen uno y no la cumplen. Para encontrar valores de correo electrónico repetidos en una tabla de clientes, el mismo patrón agrupa por email y conserva los recuentos superiores a uno. El recuento es el número de registros que comparten ese valor.

Utiliza la expresión que necesita la condición

Repite la función de agregación en HAVING: HAVING SUM(amount) > 200. PostgreSQL y SQL estándar no permiten el alias de salida total en esa condición del mismo nivel, aunque SQLite y MySQL sí lo permiten. Un alias es válido en un ORDER BY total DESC posterior.

Un valor redondeado mostrado y el valor comprobado pueden diferir. El promedio exacto de East es 260 dividido entre tres. Si seleccionas ROUND(AVG(amount), 2) pero escribes HAVING AVG(amount) > 86.67, East se elimina: su promedio sin redondear es inferior a 86,67. North permanece. La condición utiliza exactamente la expresión escrita en HAVING. Solo HAVING ROUND(AVG(amount), 2) ... comprobaría el valor redondeado.

Filtra el único grupo global

HAVING también puede funcionar sin un GROUP BY explícito. SELECT COUNT(*) FROM orders HAVING COUNT(*) > 5; trata los ocho pedidos como un grupo, supera la comprobación y devuelve una fila que contiene ocho. Sustituir la condición por COUNT(*) > 10 no devuelve filas, en lugar de devolver una fila que contenga cero.

PostgreSQL admite este patrón, al igual que SQLite desde la versión 3.39.0. En una instalación anterior de SQLite, una consulta que utiliza HAVING necesita un GROUP BY explícito.

Una condición corresponde al punto en el que existe lo que describe. Los pedidos individuales existen antes de la agrupación. Un total regional existe solo después de agrupar y sumar los pedidos.

Sigue el orden lógico

SQL se escribe como SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT. Para razonar sobre el resultado, sigue este orden lógico:

1. FROM aporta las filas.
2. WHERE conserva las filas que cumplen la condición.
3. GROUP BY forma grupos y las funciones de agregación calculan sus medidas.
4. HAVING conserva los grupos que cumplen la condición.
5. SELECT produce los valores de salida; DISTINCT elimina las filas de salida duplicadas si se solicita.
6. ORDER BY ordena el resultado y LIMIT conserva el número de filas solicitado.

La base de datos puede organizar su ejecución interna de otra manera.

Coloca cada condición en su nivel

WHERE SUM(amount) > 200 falla porque el total aún no existe en la etapa de filtrado de filas. Una condición de fila como region = 'East' puede resolverse antes de agrupar y corresponde a WHERE.

Recorre ambos filtros

SELECT region, COUNT(*) AS orders, SUM(amount) AS total FROM orders WHERE amount >= 60 GROUP BY region HAVING SUM(amount) > 200;

Primero elimina los pedidos de 45 y 30. East contiene ahora 120 y 95, North contiene 200 y 150, y West contiene 80 y 60. Después calcula los totales de 215, 350 y 140. Por último, conserva los totales superiores a 200. La salida es East con dos pedidos y 215, y North con dos y 350. La región NULL no tiene filas restantes, por lo que nunca forma un grupo.

No cambies la pregunta al mover un filtro

«Para cada región, calcula el promedio solo de los pedidos de 60 o más» utiliza WHERE amount >= 60. El promedio de East pasa a ser 107,5 a partir de 120 y 95.

HAVING MIN(amount) >= 60 pide las regiones en las que todos los importes que no son NULL alcanzan el umbral. East se elimina porque su mínimo es 45; North y West permanecen con sus pedidos originales. Mover la comprobación cambió el significado: de seleccionar pedidos individuales a aceptar o rechazar regiones completas.

Para este informe regional, region <> 'West' da el mismo resultado en WHERE o en HAVING: East y North permanecen, y el grupo NULL tampoco supera la comparación. WHERE expresa la restricción de filas directamente y la aplica antes de agrupar. Para conservar también las regiones ausentes, la condición necesita un OR region IS NULL explícito.

Los alias de SELECT no están disponibles en las cláusulas anteriores WHERE y HAVING en PostgreSQL. SQLite permite un uso más amplio de alias, pero escribir la columna o expresión de entrada completa deja clara la etapa prevista.

Dividir dos valores enteros puede descartar la fracción antes incluso de mostrar la respuesta. Esto importa cuando construyes una media o un porcentaje a partir de totales y recuentos.

Asegúrate de tener un operando decimal antes de dividir

En SQLite y PostgreSQL, 7 / 2 devuelve 3. Con valores de entrada enteros, SUM(quantity) / COUNT(*) sobre la tabla de pedidos devuelve 2: 19 artículos divididos entre ocho pedidos pierden su parte fraccionaria. En PostgreSQL, SUM de una columna INTEGER devuelve BIGINT, que aquí sigue utilizando división entera.

Escribe 1.0 * SUM(quantity) / COUNT(*) para obtener 2,375 en ambos motores. Multiplicar por 1,0 crea un operando decimal antes de la división. SUM(quantity) / COUNT(*) * 1.0 da 2,0 porque la división ya ha descartado la fracción. Las operaciones con la misma precedencia se evalúan de izquierda a derecha.

Para esta tabla, AVG(quantity) da directamente 2,375 en SQLite y PostgreSQL. La fórmula manual importa cuando necesitas un denominador diferente o un porcentaje.

Calcula un porcentaje

Tres de los ocho pedidos tienen importes de al menos 100. El recuento de esos pedidos dividido entre el recuento de todos los pedidos mide su proporción. Multiplica por 100,0:

SELECT 100.0 * COUNT(CASE WHEN amount >= 100 THEN 1 END) / COUNT(*) AS pct_large FROM orders;

El resultado es 37,5. Utilizar el entero 100 produce en cambio 37 en SQLite y en la división entre recuentos enteros de PostgreSQL. Redondear después solo cambiaría cómo se muestra 37.

Una consulta de toda la tabla puede no tener filas que coincidan. NULLIF(COUNT(*), 0) devuelve NULL cuando el recuento es cero, por lo que 100.0 * COUNT(discount) / NULLIF(COUNT(*), 0) devuelve NULL para un conjunto de entrada vacío. Un denominador cero sin protección produce un error en PostgreSQL; SQLite devuelve NULL. Una proporción NULL puede representar claramente que «no hay pedidos que medir».

Comprueba la base de datos y el tipo de entrada

En SQL Server, utiliza AVG(quantity * 1.0) o convierte los valores de entrada a DECIMAL antes de calcular el promedio. En PostgreSQL, SUM de una columna BIGINT devuelve NUMERIC, por lo que su división no tiene por qué comportarse como SUM de una columna INTEGER. MySQL devuelve DECIMAL para las sumas de valores de entrada enteros.

Una conversión de tipo también puede crear el operando decimal necesario: utiliza CAST(SUM(quantity) AS REAL) en SQLite o CAST(SUM(quantity) AS NUMERIC) en PostgreSQL. La conversión a NUMERIC de SQLite puede conservar un entero, por lo que esa conversión por sí sola no garantiza una división decimal.

Distingue los decimales exactos de las aproximaciones

Los tipos de coma flotante almacenan aproximaciones binarias. NUMERIC y DECIMAL de PostgreSQL admiten valores decimales exactos; las sumas de coma flotante pueden mostrar pequeñas anomalías como 0,30000000000000004. La afinidad NUMERIC de SQLite no proporciona almacenamiento decimal exacto. Para obtener totales monetarios exactos allí, almacena céntimos como enteros, súmalos y divide entre 100,0 para mostrarlos.

El redondeo determina cuántas cifras muestra un resultado. Conserva el cálculo completo hasta el último paso para que las decisiones de presentación no cambien la medida que estás calculando.

Redondea un resultado de agregación

ROUND(x, n) redondea a n cifras después de la coma decimal. ROUND(x) redondea a un número entero. Por ejemplo, ROUND(3.14159, 2) es 3,14.

SELECT region, ROUND(AVG(amount), 2) AS avg_amount FROM orders GROUP BY region; da East 86,67, North 175, West 70 y región NULL 30. SQLite puede mostrar 175,0, mientras que el resultado NUMERIC de PostgreSQL muestra 175,00. Ambos representan el mismo número. Redondear un número y dar formato a una etiqueta de texto de anchura fija son tareas diferentes.

Redondea después de sumar o calcular el promedio

Para tres cargos de 0,44, suma primero para obtener 1,32 y después redondea a un decimal para obtener 1,3. ROUND(SUM(fee), 1) sigue esa secuencia. SUM(ROUND(fee, 1)) redondea cada cargo a 0,4 y después los suma, lo que da 1,2. El redondeo anticipado ha cambiado el total.

Del mismo modo, ROUND(100 * 1 / 3, 1) da 33,0 en SQLite y PostgreSQL porque la división entera ya ha producido 33. ROUND(100.0 * 1 / 3, 1) conserva la fracción y da 33,3. Elige el tipo de cálculo antes de redondear.

Los porcentajes redondeados pueden no sumar 100 %. Tres partes iguales pueden mostrarse como 33,3 % cada una y sumar 99,9 %. Las proporciones originales siguen cubriendo el total. Recalcular una parte arbitraria para forzar el total mostrado cambia el significado de esa cifra.

Utiliza un tipo de entrada compatible

PostgreSQL admite ROUND(value, n) con dos argumentos para NUMERIC. Si temp es DOUBLE PRECISION, escribe ROUND(CAST(AVG(temp) AS NUMERIC), 2). El promedio de 20,5; 21,25 y 19,0 es 20,25, y la conversión te permite utilizar el redondeo con dos argumentos. Con amount de tipo entero, el promedio de PostgreSQL ya es NUMERIC, por lo que no hace falta convertirlo.

Para valores NUMERIC exactos de PostgreSQL, los casos situados justo a mitad se redondean alejándose de cero: 2,5 se convierte en 3 y -2,5 se convierte en -3. SQLite también da 3,0 y -3,0 para estos ejemplos. El redondeo de coma flotante de PostgreSQL depende de la plataforma; es habitual redondear al número par más cercano. La aproximación binaria también puede situar un decimal justo por debajo del punto medio previsto. No utilices un empate concreto de coma flotante como regla general para la aritmética decimal exacta.

Observa otras dos diferencias entre dialectos

PostgreSQL, MySQL, SQL Server y Oracle utilizan un número negativo de posiciones decimales para redondear a la izquierda de la coma decimal. ROUND(1234.5, -2) da 1200. SQLite trata un segundo argumento negativo como cero y da 1235,0. Para redondear a centenas en SQLite, utiliza ROUND(x / 100.0) * 100.

La conversión a entero también depende de la base de datos: SQLite elimina la parte fraccionaria, por lo que 2,9 se convierte en 2; PostgreSQL lo redondea a 3. Utiliza ROUND cuando quieras redondear. En cambio, TRUNC(x, n) de PostgreSQL elimina cifras: TRUNC(2.97, 1) es 2,9, mientras que redondearlo a un decimal da 3,0.

La agregación condicional permite que distintas medidas utilicen distintas aportaciones manteniendo el mismo conjunto global de filas. Una expresión CASE decide qué aporta cada fila a un recuento o una suma.

Cuenta las filas que cumplen la condición

COUNT(CASE WHEN amount >= 100 THEN 1 END) cuenta los pedidos de al menos 100. La expresión devuelve 1 cuando se cumple la condición y NULL para las demás filas porque no tiene ELSE. COUNT omite esos valores NULL, por lo que quedan tres coincidencias en la tabla de pedidos.

SUM(CASE WHEN amount >= 100 THEN 1 ELSE 0 END) cuenta las coincidencias sumando unos y ceros. Cuando existen filas de entrada, da el mismo recuento. COUNT(CASE WHEN amount >= 100 THEN 1 ELSE 0 END) no lo hace: ni 1 ni 0 son NULL, por lo que cuenta los ocho pedidos.

Suma los importes que cumplen la condición

Para obtener un total condicional, devuelve el propio importe:

SELECT region, COUNT(*) AS orders, COUNT(CASE WHEN amount >= 100 THEN 1 END) AS large_orders, SUM(CASE WHEN amount >= 100 THEN amount ELSE 0 END) AS large_total FROM orders GROUP BY region;

East tiene tres pedidos, un pedido grande y un total de pedidos grandes de 120. North tiene dos pedidos, ambos grandes, que suman 350. West tiene dos pedidos, ningún pedido grande y un total de pedidos grandes de cero. El grupo de región NULL tiene un pedido y ceros en ambas medidas de pedidos grandes.

La salida conserva West porque sus filas de entrada siguen existiendo. Añadir WHERE amount >= 100 eliminaría las filas de West antes de agrupar, por lo que West desaparecería. Ese filtro también haría que COUNT(*) contara solo los pedidos grandes, perdiendo la comparación con todos los pedidos.

Utiliza el denominador correcto

Dentro de cada región, calcula el porcentaje de pedidos grandes con ROUND(100.0 * COUNT(CASE WHEN amount >= 100 THEN 1 END) / COUNT(*), 1) AS pct_large. East da 33,3; North 100,0; West 0,0 y el grupo NULL 0,0. Cada denominador es el recuento de pedidos de ese grupo, no el recuento de ocho de toda la tabla.

Para un informe sin agrupar que pueda no tener filas, protege el denominador con NULLIF(COUNT(*), 0). Un recuento sobre un conjunto de entrada vacío es cero, pero un porcentaje de una población vacía no tiene denominador.

Crea varias columnas de categoría

Un único resultado puede mostrar un recuento por región:

SELECT COUNT(CASE WHEN region = 'East' THEN 1 END) AS east, COUNT(CASE WHEN region = 'West' THEN 1 END) AS west, COUNT(CASE WHEN region = 'North' THEN 1 END) AS north FROM orders;

Los recuentos son tres, dos y dos. El pedido de Eli no cumple ninguna de estas condiciones de región con nombre. Añade COUNT(CASE WHEN region IS NULL THEN 1 END) para contar el único pedido sin región. Comparar una región NULL con un nombre no produce una condición verdadera.

Reconoce sintaxis alternativas

PostgreSQL y SQLite desde la versión 3.30.0 admiten COUNT(*) FILTER (WHERE amount >= 100). El filtro se aplica a esa función de agregación, por lo que un COUNT(*) contiguo sin filtro sigue contando todos los pedidos. MySQL y SQL Server no admiten esta sintaxis FILTER de agregación; la forma con CASE funciona en ambos.

SQLite y MySQL también permiten SUM(amount >= 100) porque las comparaciones producen valores de verdad numéricos. PostgreSQL rechaza SUM de valores booleanos. Utiliza la forma con CASE cuando una consulta deba funcionar en todos estos motores.

Una consulta de resumen empieza con una pregunta sobre una población con un nivel de detalle concreto. Traduce esas decisiones antes de escribir SQL y después comprueba que la salida siga respondiendo la pregunta original.

Construye el informe en orden

Plantea: «Para cada mes de 2026 con al menos tres pedidos, ¿cuántos pedidos se hicieron y cuál fue el importe medio, con dos decimales?».

1. Las medidas son COUNT(*) y AVG(amount).
2. La granularidad, o significado de una fila de resultado, es un mes del calendario.
3. La condición de fila conserva las fechas de 2026.
4. La condición de grupo exige al menos tres pedidos.
5. La salida debe ordenarse por mes, con el promedio redondeado para mostrarlo.

En SQLite:

SELECT strftime('%Y-%m', order_date) AS month, COUNT(*) AS orders, ROUND(AVG(amount), 2) AS avg_amount FROM orders WHERE order_date >= '2026-01-01' AND order_date < '2027-01-01' GROUP BY strftime('%Y-%m', order_date) HAVING COUNT(*) >= 3 ORDER BY month;

Para valores de fecha de PostgreSQL, sustituye la expresión de mes en ambos lugares por to_char(order_date, 'YYYY-MM'). El intervalo de fechas incluye el inicio de 2026 y excluye el inicio de 2027.

Enero tiene dos pedidos y no cumple la condición de grupo. Febrero tiene tres pedidos que suman 305, con un promedio de 101,67. Marzo tiene tres que suman 275, con un promedio de 91,67. Los grupos que permanecen representan seis pedidos, no ocho, porque HAVING ha eliminado enero.

Comprueba antes de eliminar grupos con el filtro

Ejecuta primero el informe sin HAVING. Los recuentos de todos los grupos deben sumar el recuento de filas bajo el mismo filtro WHERE, y los totales deben sumar el total sin agrupar. Aquí esas comprobaciones dan ocho y 780. No compares los totales de los grupos conservados con todo el conjunto de entrada después de excluir algunos grupos.

Busca un grupo NULL, examina el orden de los resultados y vuelve a calcular un grupo filtrando la tabla original. Para East, WHERE region = 'East' debe dar tres pedidos que sumen 260. Una discrepancia puede revelar una columna de agrupación adicional, un filtro de filas mal colocado o una expresión que se haya convertido en NULL.

Distingue el promedio por pedido del promedio por cliente

AVG(amount) es 97,5 por pedido. El gasto medio por cliente pide una unidad diferente: los cinco totales de cliente son 165, 140, 350, 95 y 30. Su promedio es 156.

Calcúlalo en dos etapas:

SELECT AVG(total) AS avg_customer_total FROM (SELECT customer, SUM(amount) AS total FROM orders GROUP BY customer) AS per_customer;

La consulta interna crea una fila por cliente. La consulta externa calcula el promedio de esas filas, de modo que cada cliente aporta una vez. Si todos los clientes están identificados, 1.0 * SUM(amount) / COUNT(DISTINCT customer) da el mismo 156. Cuando los números de pedidos son desiguales, calcular el promedio de los importes de pedido es un cálculo diferente.

Resume los propios grupos

Para contar los clientes con más de un pedido, primero enuméralos y después cuenta sus filas:

SELECT COUNT(*) FROM (SELECT customer FROM orders GROUP BY customer HAVING COUNT(*) > 1) AS repeat_customers;

La respuesta es tres. Anidar directamente funciones de agregación, como en MAX(AVG(amount)) en un mismo nivel de consulta, falla en SQLite y PostgreSQL. Para encontrar la región con el promedio más alto, ordena los promedios agrupados: ORDER BY AVG(amount) DESC LIMIT 1 devuelve North con 175. Oracle también admite funciones de grupo anidadas, pero un nivel de consulta separado hace explícitos los dos cálculos. Comprueba los empates cuando un informe pida un resultado máximo.