A la lliçó anterior vas obtenir una xifra per a tota l'empresa: 727,95 € de facturació. És una dada, però no és una anàlisi. El que la direcció pregunta de debò no és "quant hem venut?", sinó "quant hem venut de cada cosa?": per categoria, per client, per país, per mes, per comercial. Aquella paraula —per— és el senyal inequívoc que toca GROUP BY.

GROUP BY parteix el conjunt de files en grups i aplica l'agregat a cada grup per separat, retornant una fila per grup en comptes d'una per a tot. És, sense exagerar, la clàusula que converteix SQL en una eina d'anàlisi. En aquesta lliçó aprendràs a agrupar per una columna, per diverses i per una expressió; ampliaràs per fi el diagrama de l'ordre lògic d'execució amb GROUP BY i HAVING —ho vam prometre a 02-01—; veuràs per què els NULL formen el seu propi grup; dominaràs el patró central de l'anàlisi, que és GROUP BY combinat amb JOIN; i descobriràs per què la categoria 6 de BotigaVerda desapareix dels teus informes i què cal fer perquè hi aparegui amb un honest 0.

1. GROUP BY: partir en grups i agregar cadascun
2. L'ordre lògic d'execució, ampliat
3. La regla d'or: agrupada o agregada
4. Agrupar per una columna
5. Agrupar per diverses columnes
6. Agrupar per una expressió
7. GROUP BY i l'àlies del SELECT
8. Grups i NULL
9. GROUP BY amb JOIN: el patró central de l'anàlisi
10. Grups buits: per què la categoria 6 no apareix
11. Ordenar per l'agregat i quedar-se amb el top N
12. ROLLUP, GROUPING SETS i CUBE
13. Errors habituals i consells
14. Exercicis
15. Conclusió

La idea és visual. Sense GROUP BY, totes les files van a un únic munt. Amb GROUP BY, es reparteixen en munts segons el valor d'una columna, i l'agregat es calcula a cada munt:

I la consulta:

5 files, una per estat. Compara-ho amb el que hauries hagut de fer sense GROUP BY: cinc consultes amb WHERE estat = '…', o una amb cinc COUNT(*) FILTER (...). I si demà aparegués un sisè estat, GROUP BY el mostraria sol, mentre que les altres dues versions caldria reescriure-les.

El principi general: GROUP BY produeix una fila per cada combinació diferent de valors de les columnes agrupades. El nombre de files del resultat és exactament el nombre de valors diferents, ni un més ni un menys.

Des de 02-01 véns construint un diagrama de l'ordre en què SQL entén una consulta. El mòdul 2 el va deixar en cinc passos i el mòdul 3 va mostrar que els JOIN passen dins del FROM. Ara hi inserim les dues peces que faltaven, entre WHERE i SELECT:

Aquest diagrama no és decoració: explica per si sol gairebé tot el que ve després. Tres conseqüències immediates:

Aquesta última té un matís important a PostgreSQL, i li dediquem la secció 7 sencera.

El raonament que cal tenir sempre present: un cop s'executa GROUP BY, les files individuals deixen d'existir com a tals. A partir del pas 3, el conjunt de treball ja no són 47 línies de comanda: són 5 grups. Tot el que escriguis d'aquí endavant ha de tenir sentit a nivell de grup.

És una sola frase, i d'ella se'n dedueix tota la resta:

Tota expressió del SELECT ha d'estar (a) al GROUP BY, o (b) dins d'una funció d'agregació. Sense excepcions.

Veure-la fallar és la millor manera d'entendre-la:

I el motor té raó. La fila del grup "Alimentació" representa cinc productes: l'oli, l'arròs, la mel, la pasta i el tomàquet. Quin dels cinc noms hauria d'aparèixer en aquella cel·la? No hi ha cap resposta possible, així que PostgreSQL es nega a inventar-se'n una.

Les tres sortides vàlides:

L'opció b és especialment útil, i demostra que la regla no és un caprici:

6 files, una per categoria, amb els 20 productes repartits: 5 + 4 + 4 + 4 + 2 + 1 = 20. STRING_AGG ha respost a "quins són?" sense trencar la regla, perquè és un agregat.

PostgreSQL és una mica més llest del que suggereix l'enunciat: si agrupes per la clau primària d'una taula, et deixa seleccionar qualsevol altra columna d'aquella mateixa taula, perquè la PK determina funcionalment la resta de valors.

Funciona perquè cat.id és PRIMARY KEY: dins d'un grup amb el mateix id només hi pot haver un nom, així que no hi ha ambigüitat. És una comoditat molt pràctica —evita haver de repetir cinc columnes al GROUP BY— i forma part de l'estàndard SQL des del 1999.

Nota de dialecte — i per què la permissivitat de MySQL és un parany.

Motor	Permet una columna solta amb un agregat?	Què retorna
PostgreSQL	No (llevat de dependència funcional de la PK)	Error explícit
MySQL amb ONLY_FULL_GROUP_BY (per defecte des de 5.7.5)	No	Error explícit
MySQL amb ONLY_FULL_GROUP_BY desactivat	Sí	Un valor arbitrari de qualsevol fila del grup
SQLite	Sí, sempre	Un valor arbitrari (amb l'excepció documentada de MIN/MAX, on retorna el d'aquella fila)
SQL Server	No	Error explícit
Oracle	No	Error explícit

El cas de MySQL permissiu és el parany: la consulta no falla, i en proves amb poques dades fins i tot sembla retornar "el primer", que sol ser el que un esperava. En producció, amb un altre pla d'execució, en retorna un altre. Un informe que deia "Alimentació — Oli d'oliva — 5 productes" comença a dir "Alimentació — Tomàquet triturat — 5 productes" sense que ningú no hagi tocat res. Si treballes amb MySQL, comprova que ONLY_FULL_GROUP_BY està actiu i no el desactivis.

4 files que sumen 20 comandes i 118,25 € de ports: les mateixes xifres mestres de 04-04, ara desglossades. I ja s'hi llegeix una història: la targeta domina (11 de 20) i el contrareemborsament és el mètode amb els ports més cars (9,50 € de mitjana), cosa que té sentit perquè són els enviaments més llunyans.

3 files. Fixa't en COUNT(DISTINCT ciutat): 11 clients espanyols repartits en només 7 ciutats, perquè València en concentra quatre i Barcelona dues.

6 files, les 6 categories, perquè estem agrupant la taula productes i tots els productes tenen categoria. Guarda't aquest detall: a la secció 10 veuràs que agrupar les vendes per categoria només dona 5 files, i entendre per què és la diferència entre un informe honest i un d'incomplet.

Fixa't en el que passa amb la categoria 6: un sol producte, així que AVG, MIN i MAX coincideixen. Els agregats sobre un grup d'una fila retornen aquell mateix valor.

En llistar diverses columnes al GROUP BY, el motor forma un grup per cada combinació diferent de valors.

8 files. Compte amb un punt important: no són 3 països × 5 estats = 15 files. GROUP BY produeix una fila per cada combinació que existeix a les dades, no per cada combinació possible. No hi ha cap comanda francesa cancel·lada, així que aquella fila no hi apareix — no hi apareix amb un zero, és que directament no existeix. (Si necessitessis la graella completa, incloses les combinacions buides, el camí seria un CROSS JOIN de 03-06 amb un LEFT JOIN a sobre.)

L'ordre de les columnes al GROUP BY no canvia el resultat, només la interpretació mental. GROUP BY c.pais, co.estat i GROUP BY co.estat, c.pais retornen els mateixos 8 grups. El que sí que canvia l'aspecte de l'informe és l'ORDER BY.

I el cas clàssic d'anàlisi: vendes per categoria i any.

9 files, no 10: Llar sostenible no ha venut res el 2026, així que aquella combinació no existeix. És el mateix fenomen d'abans, i en un informe d'evolució és exactament la mena de buit que cal saber llegir.

(EXTRACT(YEAR FROM …) extreu l'any d'una data. Les funcions de data s'estudien a fons a 06-03; aquí és només un instrument.)

No estàs limitat a columnes: pots agrupar per qualsevol expressió calculada a partir d'elles. És el que acabes de fer amb EXTRACT, i és el que permet construir trams, cohorts i segmentacions.

Agrupem el catàleg per rang de preu:

4 trams que sumen els 20 productes. El catàleg de BotigaVerda està clarament escorat cap al producte barat: 13 de 20 referències costen menys de 10 €.

Dues coses d'aquesta consulta mereixen comentari:

1. L'expressió apareix dues vegades, idèntica, al SELECT i al GROUP BY. És lletja i és necessària, pel motiu de sempre: l'àlies rang_preu encara no existeix quan s'executa el GROUP BY. (Llevat a PostgreSQL, que fa una concessió — secció 7.) Les maneres d'evitar la repetició són les subconsultes del mòdul 7 i les CTE del mòdul 10.
2. El prefix numèric de les etiquetes (1 · , 2 · …) no és decoratiu. ORDER BY rang_preu ordena alfabèticament, i sense el prefix l'ordre seria "de 10 a 15 €", "de 5 a 10 €", "15 € o més", "menys de 5 €": un desastre. És un truc habitual en construir trams.

CASE s'estudia a fons a 06-05; aquí es fa servir com a eina per classificar.

Aquest punt s'explica malament en molts llocs, així que serem precisos.

Segons l'ordre lògic, el GROUP BY (pas 3) s'executa abans que el SELECT (pas 5), on neixen els àlies. Per tant, l'estàndard SQL no permet fer servir un àlies del SELECT al GROUP BY.

A la pràctica, PostgreSQL fa una concessió: accepta que un element del GROUP BY sigui el nom d'una columna de sortida (un àlies) o el seu número ordinal. És una extensió del motor, documentada i molt còmoda:

També funciona per número ordinal, GROUP BY 1, encara que aquella forma és fràgil: si algú afegeix una columna al principi del SELECT, l'1 passa a referir-se a una altra cosa.

Ara les tres limitacions d'aquella concessió, que són les que produeixen els errors confusos.

Tan bon punt l'àlies entra en una expressió més gran, PostgreSQL deixa de resoldre'l com a nom de sortida i el busca com a columna de la taula, on no existeix.

Aquesta és la perillosa. Si un àlies del SELECT coincideix amb el nom d'una columna real de la taula, PostgreSQL fa servir la columna de la taula, no el teu àlies:

El missatge sembla absurd —"però si he escrit GROUP BY categoria_id, que és justament l'àlies de proveidor_id"— fins que entens la regla: el GROUP BY ha resolt categoria_id com a productes.categoria_id, la columna real. I aleshores proveidor_id queda solta al SELECT, que és exactament el que l'error denuncia. Un àlies que ombreja el nom d'una columna és sempre mala idea.

La concessió de PostgreSQL cobreix GROUP BY i ORDER BY, però no HAVING. Allà cal repetir l'agregat sencer: HAVING COUNT(*) > 3. Ho desenvolupa la lliçó 04-06.

Recomanació del curs: encara que PostgreSQL t'ho permeti, repeteix l'expressió completa al GROUP BY. És més llarg, sí, però és portable, no depèn de regles de resolució de noms i funciona igual a les quatre clàusules. Reserva els àlies per a l'ORDER BY, on són estàndard i no tenen sorpreses.

A 04-03 vas veure la taula d'on els NULL es consideren iguals entre si, i GROUP BY era a la llista. Aquí el tens en acció, i és una de les coses més útils de tota la lliçó:

4 grups, i el quart és el dels NULL: 10 comandes del canal web amb 46,10 € de ports. GROUP BY ha ajuntat els deu nuls en un sol grup, tot i que NULL = NULL sigui UNKNOWN.

I això és exactament el que vols: el canal web és una categoria de negoci real i mereix la seva fila. Compara-ho amb el que hauria passat si el disseny hagués fet servir un sentinella (empleat_id = 0): el grup existiria igual, però a més s'esmunyiria a COUNT(DISTINCT empleat_id) com si fos un comercial de debò, donant 4 en lloc de 3.

Perquè l'informe es llegeixi bé, la fila del nul necessita una etiqueta. Amb COALESCE (06-04) o CASE (06-05) es resol; de moment, el NULLS LAST de l'ORDER BY (02-05) almenys la col·loca on toca.

El mateix amb els referits:

7 files. El grup nul (7 clients que van arribar pel seu compte) és el més gran, i la Lucía Martínez Soler (id 1) és la millor prescriptora amb 3 recomanats. Aquesta és una dada accionable que cap consulta anterior del curs no podia donar.

Arribem al que de debò es fa cada dia a qualsevol empresa. La consulta canònica de quatre taules de 03-02 continua sent la base; l'únic que canvia és que ara hi posem GROUP BY a sobre.

Aquestes són les xifres de facturació per categoria de BotigaVerda. Sumen 727,95 €, el total de 04-04. I ja expliquen una història comercial: Alimentació lidera en facturació i en unitats (49 de 113), mentre que Cosmètica natural factura 156,32 € amb només 16 unitats — el seu tiquet per unitat és gairebé cinc vegades més gran.

Cinc files, no sis. Hi falta Complements. Hi tornarem a la secció 10.

12 files —els 12 clients que han comprat— i el rànquing de clients de BotigaVerda: Sofia Moreira Costa lidera amb 111,88 €, seguida molt de prop per Lucía Martínez Soler amb 107,60 € repartits en tres comandes.

Dos detalls tècnics que cal veure:

• COUNT(DISTINCT co.id) és imprescindible. COUNT(*) compta línies, no comandes: la Lucía té 9 línies en 3 comandes. És la multiplicació de files de 03-02, i DISTINCT és la manera de desfer-la en comptar.
• Totes les columnes no agregades són al GROUP BY. Com que c.id és la PK de clients, PostgreSQL ens permetria escriure només GROUP BY c.id; s'han llistat totes perquè la consulta sigui portable.

I l'avís, ara resolt: si afegissis SUM(co.despeses_enviament) a aquesta consulta obtindries un número inflat, perquè cada comanda hi apareix tantes vegades com línies tingui. La Lucía pagaria els seus ports nou vegades. És exactament el problema de 04-04 secció 11, i la solució és la mateixa: agregar els ports en una consulta a part (o, des del mòdul 7, amb una subconsulta que col·lapsi les línies abans d'unir).

(6 primeres de 17 files.)

17 files en total, no 20: els productes 13, 19 i 20 no s'han venut mai i no hi apareixen. I observa el contrast entre les dues primeres columnes: l'arròs i el tomàquet empaten en unitats (14), però l'arròs factura més del doble perquè costa el doble. El producte més venut en unitats i el que més factura gairebé mai no són el mateix, i per això un informe de vendes necessita totes dues mètriques.

Torna a la secció 9.1: cinc categories a l'informe de vendes, sis al catàleg. Complements ha desaparegut.

No és un error del GROUP BY. És l'INNER JOIN de 03-02 fent el que fa: descartar el que no casa. L'únic producte de Complements (l'espirulina) no apareix a linies_comanda, així que cap fila del FROM no pertany a aquella categoria, i un grup que no té files no existeix.

GROUP BY no inventa grups: només reparteix les files que li arriben.

6 files. Aquí tens Complements, amb la veritat: 0 línies, 0 unitats i una facturació nul·la.

Tres decisions d'aquella consulta mereixen explicació, i són la part més important de la secció:

1. COUNT(lc.id) i no COUNT(*). Això és crític. La fila de Complements existeix al resultat del LEFT JOIN —amb totes les columnes de linies_comanda a NULL—, així que COUNT(*) la comptaria i retornaria 1, no 0. COUNT(lc.id) compta només els valors no nuls i retorna l'honest 0.

És la regla de 04-04 secció 3 aplicada al cas que més importa. En qualsevol GROUP BY sobre un LEFT JOIN, compta sempre una columna de la taula de la dreta, mai *.

2. La facturació surt *(null)* i no 0.00. Perquè SUM d'un conjunt buit és NULL (04-04, secció 7). Per presentar-lo com a 0.00 caldria COALESCE(SUM(...), 0), que és el que hem fet amb les unitats. COALESCE és de 06-04; aquí s'ha fet servir una vegada perquè vegis el contrast entre les dues columnes.

3. Els dos JOIN són LEFT. Recorda la regla de 03-03 secció 7: un INNER JOIN després d'un LEFT JOIN n'anul·la l'efecte. Si el segon salt fos JOIN linies_comanda, Complements tornaria a desaparèixer.

3 files, els mateixos tres productes mai venuts que vas trobar amb l'anti-join de 03-03, ara amb el diagnòstic al costat: sense estoc, amb problema comercial, descatalogat. (El HAVING és la lliçó següent; aquí apareix de passada perquè és la manera natural de filtrar per un recompte.)

La regla que cal endur-se: un INNER JOIN respon a "quant ha venut cada categoria que ha venut alguna cosa?"; un LEFT JOIN respon a "quant ha venut cada categoria?". La segona és gairebé sempre la pregunta del negoci, perquè un zero també és informació: li diu a la direcció que Complements no està funcionant. Un informe que amaga els zeros amaga precisament els problemes.

ORDER BY s'executa després del SELECT (pas 6 del diagrama), així que pot ordenar per un agregat o pel seu àlies sense problema:

El top 5 de productes per facturació de BotigaVerda. L'oli d'oliva és el producte estrella amb 109,53 €, el 15 % de tota la facturació.

Fixa't en dues coses:

• L'ORDER BY acaba amb p.id, una columna única, com mana la convenció del curs des de 02-05. Sense ella, dos productes amb la mateixa facturació podrien sortir en ordre diferent a cada execució i la paginació seria inestable.
• També es pot ordenar per un agregat que no és al SELECT: ORDER BY SUM(lc.quantitat) DESC és perfectament legal encara que no mostris les unitats. És legal i de vegades confús, així que fes-ho servir amb compte.

La combinació GROUP BY + ORDER BY agregat DESC + LIMIT n és el patró top N, i és probablement la consulta analítica més demanada que existeix: els 10 clients que més compren, els 5 productes que menys roten, els 3 comercials amb més vendes.

Nota: si el que vols és un top N dins de cada grup —"els 3 productes més venuts de cada categoria"—, GROUP BY i LIMIT no en tenen prou: cal una funció de finestra (ROW_NUMBER() OVER (PARTITION BY ...)), i això és el mòdul 10.

Un informe real gairebé sempre necessita subtotals i un total general al costat del detall. Escriure això amb UNION ALL de diverses consultes és tediós i lent, perquè obliga a recórrer la taula diverses vegades. SQL ofereix tres extensions del GROUP BY per resoldre-ho en una sola passada:

Un exemple mínim amb ROLLUP, sobre les vendes per categoria i any de la secció 5:

15 files: les 9 combinacions reals, 5 subtotals per categoria i el total general de 727,95 € a l'última. Les files de subtotal es reconeixen perquè les columnes agrupades de nivell inferior valen NULL.

I aquí hi ha l'única complicació de ROLLUP: aquells NULL de subtotal són indistingibles d'un NULL de dada. La funció GROUPING(columna) serveix per diferenciar-los (retorna 1 si la fila és un subtotal per aquella columna), i combinada amb CASE (06-05) permet etiquetar les files com a "Total categoria" o "TOTAL GENERAL".

No hi aprofundim més: ROLLUP i companyia es fan servir molt en informes de direcció i en eines de business intelligence, però el seu lloc natural és després de dominar CASE i les subconsultes.

Nota de dialecte: ROLLUP, CUBE i GROUPING SETS existeixen a PostgreSQL 9.5+, SQL Server i Oracle. MySQL només té GROUP BY ... WITH ROLLUP (sintaxi diferent i sense CUBE ni GROUPING SETS). SQLite no en té cap: cal emular-los amb UNION ALL.

• Posar al SELECT una columna que no està agrupada ni agregada. column ... must appear in the GROUP BY clause. És l'error més freqüent de la lliçó, i a MySQL permissiu o a SQLite no dona error: retorna un valor arbitrari.
• Fer servir COUNT(*) en un GROUP BY sobre un LEFT JOIN. Retorna 1 on hauria de retornar 0. Compta una columna de la taula dreta: COUNT(lc.id).
• Esperar que apareguin els grups buits amb un INNER JOIN. La categoria 6 no hi surt. Si l'informe ha de llistar totes les categories, comença per categories amb LEFT JOIN.
• Ficar un INNER JOIN després del LEFT JOIN a la mateixa cadena. Anul·la el LEFT i els grups buits tornen a desaparèixer (03-03).
• Sumar una columna de capçalera després d'unir amb el detall. Continua sent l'error de 04-04: els ports de la Lucía es comptarien nou vegades.
• Comptar comandes amb COUNT(*) en una consulta que parteix de linies_comanda. Compta línies. Fes servir COUNT(DISTINCT co.id).
• Fer servir un àlies del SELECT al HAVING. column "..." does not exist a PostgreSQL. Repeteix l'agregat.
• Donar per fet que GROUP BY genera totes les combinacions possibles. Només genera les que existeixen a les dades: 8 files de país × estat, no 15.
• Ordenar trams alfabèticament sense prefix numèric. "de 10 a 15 €" va abans que "de 5 a 10 €". Numera les etiquetes.
• Oblidar la columna única al final de l'ORDER BY. Amb empats, l'ordre deixa de ser determinista.
• Consell: escriu primer la consulta sense agregar i mira les files. Si el detall no és el que esperes, l'agregat que hi posis a sobre estarà malament encara que compili.
• Consell: valida que els grups sumin el total. 256,27 + 195,28 + 156,32 + 88,58 + 31,50 = 727,95 €. Si no quadra amb la xifra global, hi ha files perdudes o duplicades.
• Consell: compta els grups que esperes abans d'executar. Si agrupes per estat han de sortir com a màxim 5 files (el domini del CHECK); si en surten 6, hi ha un valor inesperat a les dades.

Logística vol un informe d'activitat per comercial. Escriu una consulta sobre comandes i empleats que retorni, per als 8 empleats (apareguin o no a comandes): el seu id, nom complet, càrrec, nombre de comandes gestionades i suma de despeses d'enviament d'aquelles comandes.

Ordena per nombre de comandes descendent. Després respon:

1. Quantes files retorna i per què?
2. Què hauria passat amb un INNER JOIN?
3. Per què no hi pot aparèixer el canal web?

Màrqueting vol segmentar el catàleg per proveïdor. Escriu una consulta que retorni, per a cada proveïdor: el seu nom, el seu país, si està actiu, quants productes subministra, el preu mitjà d'aquells productes (dos decimals) i les unitats venudes de tots ells.

Hi ha d'aparèixer també el proveïdor inactiu. Després respon: quantes unitats ha venut EcoNordic Supplies tot i estar inactiu, i què et diu això del negoci?

Direcció vol l'informe de vendes per mes de tot l'històric, amb aquestes columnes: mes (en format AAAA-MM), nombre de comandes diferents, nombre de línies, unitats i facturació.

1. Escriu-lo. (Pista: pots agrupar per l'expressió TO_CHAR(co.data_comanda, 'YYYY-MM'), una funció de cadena que veuràs a fons a 06-03.)
2. Identifica el millor mes i el pitjor.
3. Explica per què la suma de les facturacions mensuals ha de donar 727,95 € i comprova-ho.

Solució 1

1. 8 files, els 8 empleats. El LEFT JOIN des d'empleats conserva els cinc que no han gestionat mai cap comanda, i COUNT(co.id) els dona un 0 correcte (amb COUNT(*) haurien sortit amb 1). COALESCE converteix el NULL de SUM en un 0.00 presentable.

2. Amb INNER JOIN en sortirien 3 files: només l'Óscar, la Laia i en Marc. Desapareixerien la Rosa, l'Andrés, la Beatriz, la Irene i en Daniel — que és exactament el que passava a 03-04, on els vas conèixer com "els empleats que no han gestionat mai una comanda". Un informe de recursos humans amb 3 de 8 persones no és un informe.

3. El canal web no hi pot aparèixer perquè aquelles 10 comandes tenen empleat_id a NULL i no casen amb cap fila d'empleats. En partir d'empleats amb LEFT JOIN, aquelles files queden al costat dret sense parella i es descarten: la suma de la columna comandes dona 10, no 20. Per veure-les caldria partir de comandes (GROUP BY empleat_id, secció 8) o fer servir un FULL OUTER JOIN (03-05). És l'asimetria del LEFT JOIN en estat pur: decideix quin costat surt sencer, i l'altre perd els seus orfes.

Solució 2

5 files, els cinc proveïdors, amb els 20 productes repartits: 5 + 3 + 4 + 4 + 4 = 20. Dos detalls importants d'aquesta consulta:

• COUNT(DISTINCT p.id) i no COUNT(p.id). Després del segon LEFT JOIN, cada producte apareix tantes vegades com s'hagi venut: l'oli hi seria cinc vegades. COUNT(p.id) donaria 16 per a Huerta del Turia en lloc de 5. És la multiplicació de files de 03-02, i DISTINCT n'és la correcció.
• AVG(p.preu) també n'està afectada, i aquesta sí que no té arranjament amb DISTINCT. El preu mitjà de Huerta del Turia surt 6,73 €, no la mitjana simple dels seus cinc productes (que és 5,74 €), perquè la mitjana queda ponderada pel nombre de vegades que s'ha venut cada referència: l'oli de 12,50 € hi entra cinc vegades i el tomàquet d'1,95 € només dues. És una mitjana legítima —"preu mitjà del que es factura"— però no és la que demanava l'enunciat. Per al preu mitjà de catàleg cal calcular-lo en una consulta a part sobre productes, o amb una subconsulta (mòdul 7). És exactament el parany de granularitat de 04-04, ara sobre una mitjana en lloc d'una suma, i és més insidiós perquè el número resultant sembla plausible.

EcoNordic Supplies ha venut 12 unitats tot i estar inactiu, perquè proveidors.actiu = false significa "ja no li comprem", no "els seus productes desapareixen del catàleg". Les seves quatre referències són el detergent (10), les espelmes (13), el raspall de bambú (18) i l'espirulina (20); dues d'elles no s'han venut mai, però el raspall de bambú ha col·locat 9 unitats i el detergent 3. La dada accionable és clara: hi ha dos productes que es venen amb normalitat i el proveïdor dels quals ja no està operatiu. És un problema d'aprovisionament a tocar, i aquesta consulta és exactament la que el detecta.

Solució 3

2. El millor mes és l'octubre del 2025 amb 97,20 €, seguit molt de prop pel juny del 2025 amb 95,48 €. El pitjor és el novembre del 2025 amb 31,70 €, un mes amb una sola comanda. Amb volums tan petits, un mes bo o dolent depèn de si va caure una comanda gran, i això és una lliçó d'anàlisi: amb 20 comandes no es pot parlar d'estacionalitat.

3. La suma ha de donar 727,95 € perquè cadascuna de les 47 línies pertany exactament a una comanda, cada comanda té exactament una data, i cada data pertany exactament a un mes. Els grups són una partició del conjunt de línies: no se solapen i no deixen res fora. Comprovació:

I el recompte de línies: 5+5+5+5+3+2+2+5+3+5+4+3 = 47. Totes dues quadren.

Aquesta comprovació —els grups sumen el total?— és la millor validació que existeix per a una consulta agregada, i mereix convertir-se en un reflex. Si no quadra, o has perdut files (un INNER JOIN que descarta) o les has duplicat (un JOIN que multiplica).

GROUP BY és la clàusula que converteix SQL en anàlisi:

• Parteix les files en grups i aplica l'agregat a cadascun, retornant una fila per cada combinació diferent que existeixi a les dades — mai per combinacions que no existeixin.
• L'ordre lògic d'execució queda complet: FROM/JOIN → WHERE (files) → GROUP BY (grups) → HAVING (grups) → SELECT (àlies) → DISTINCT → ORDER BY → LIMIT. D'aquí en surt que WHERE no pugui fer servir agregats i HAVING sí.
• La regla d'or: tota columna del SELECT està agrupada o agregada. PostgreSQL, SQL Server i Oracle ho exigeixen; MySQL amb ONLY_FULL_GROUP_BY desactivat i SQLite retornen un valor arbitrari, i això és un parany, no una comoditat.
• Pots agrupar per una columna, per diverses (una fila per combinació existent) i per una expressió (EXTRACT, CASE, TO_CHAR), repetint-la íntegra al GROUP BY.
• PostgreSQL accepta un àlies del SELECT al GROUP BY com a extensió, però només nu, amb la columna real guanyant en cas d'ambigüitat, i mai a HAVING. Repetir l'expressió és sempre més segur.
• Els NULL formen el seu propi grup: les 10 comandes del canal web i els 7 clients espontanis apareixen com una fila amb *(null)*, i aquella fila és informació valuosa.
• GROUP BY amb JOIN és el patró central de l'anàlisi. Ja tens les xifres clau de BotigaVerda: facturació per categoria (Alimentació 256,27 € · Begudes 195,28 € · Cosmètica 156,32 € · Llar 88,58 € · Higiene 31,50 €), rànquing de clients (Sofia 111,88 € · Lucía 107,60 €) i top de productes (oli 109,53 € · matcha 88,00 €).
• Els grups buits no existeixen per a un INNER JOIN. La categoria 6 només apareix amb un LEFT JOIN des de categories i COUNT(lc.id) en lloc de COUNT(*), que és el que la converteix en un 0 honest en comptes d'un fals 1.
• El patró top N és GROUP BY + ORDER BY agregat DESC + LIMIT; el top N per grup necessita funcions de finestra (mòdul 10), igual que qualsevol càlcul que hagi d'agregar sense col·lapsar les files.
• ROLLUP, CUBE i GROUPING SETS afegeixen subtotals i totals en una sola passada: el ROLLUP de categoria i any va donar 15 files amb els 5 subtotals i el total general de 727,95 €.

A l'última lliçó del mòdul, la clàusula HAVING, tancaràs el cercle. Ja saps formar grups; ara aprendràs a filtrar-los: categories amb més de N productes, clients amb més d'una comanda, productes que superen cert volum. Veuràs per què HAVING pot fer servir agregats i WHERE no —el diagrama de la secció 2 t'ho dirà sol—, per què WHERE és sempre preferible quan la condició es pot avaluar fila a fila, i tindràs per fi la taula que compara els tres llocs on es pot filtrar en SQL: ON, WHERE i HAVING, tancant el fil que 03-03 va deixar obert.