Les taules de BotigaVerda no tenen files duplicades: cadascuna té la seva clau primària id, així que no n'hi ha dues d'iguals. I tanmateix, tan bon punt projectes només una part de les columnes, comencen a aparèixer repeticions per tot arreu. Preguntar "a quins països tinc clients?" sobre una taula de quinze files retorna quinze respostes quan només hi ha tres països diferents. En aquesta lliçó aprendràs per què passa, com ho resol DISTINCT, per què actua sobre la combinació completa de columnes del SELECT (el malentès més habitual del mòdul), on encaixa a l'ordre lògic d'execució, i quan l'aparició de DISTINCT en una consulta és en realitat el senyal que la consulta està mal plantejada.

1. Per què apareixen files repetides
2. DISTINCT sobre una columna
3. DISTINCT sobre diverses columnes: el malentès clàssic
4. On encaixa DISTINCT a l'ordre lògic
5. DISTINCT combinat amb WHERE i amb ORDER BY
6. COUNT(DISTINCT columna): un avanç del mòdul 4
7. DISTINCT ON: l'extensió de PostgreSQL
8. El cost de DISTINCT i quan delata un error
9. Errors habituals i consells
10. Exercicis
11. Conclusió

Comencem pel problema:

15 files. Una per client, perquè SELECT retorna una fila de resultat per cada fila d'origen. La projecció ha eliminat les columnes que feien única cada fila (id, email, nom...), i el que queda es repeteix.

És important entendre que això no és una fallada de les dades. Al model relacional pur una relació és un conjunt i no admet duplicats, però SQL no treballa amb conjunts sinó amb multiconjunts (bags): permet repeticions i només les elimina si li ho demanes explícitament. Va ser una decisió pragmàtica dels dissenyadors del llenguatge: eliminar duplicats costa temps, i a la majoria de les consultes no cal.

El mateix amb les ciutats:

Retorna 15 files amb València quatre vegades i Barcelona dues.

La paraula clau DISTINCT s'escriu immediatament després de SELECT i elimina les files repetides del resultat:

3 files. Ara sí que has respost a la pregunta "a quins països tinc clients?".

11 files de les 15: València hi apareixia 4 vegades i Barcelona 2.

Un altre cas útil: saber quins mètodes de pagament es fan servir realment. La restricció CHECK de la taula n'admet quatre, però es fan servir tots?

Els quatre. I els estats:

Els cinc valors del domini hi són representats.

Molt important: DISTINCT no ordena. Els resultats de dalt surten en un ordre que PostgreSQL tria segons com hagi eliminat els duplicats (normalment amb una taula hash, l'ordre de la qual és impredictible). Podries veure perfectament França, Espanya, Portugal. Si vols un ordre concret, ORDER BY (secció 5).

Dos detalls de sintaxi:

1. DISTINCT afecta tota la llista de columnes, no la que té al costat. SELECT DISTINCT pais, ciutat no és "el país diferent i la ciutat": és la secció 3.
2. DISTINCT(pais) funciona, però és enganyós: aquests parèntesis són els d'una expressió, no els d'una funció. SELECT DISTINCT (pais), ciutat continua aplicant DISTINCT a les dues columnes. No escriguis DISTINCT amb parèntesis; indueix a error qui ho llegeixi.

I un apunt sobre nuls: per a DISTINCT, tots els NULL compten com un mateix valor i es col·lapsen en una sola fila. És una excepció deliberada a la regla que NULL no és igual a NULL, i la veuràs a l'exercici 3.

Aquesta és la part que cal interioritzar bé:

11 files, i Espanya hi apareix set vegades. No havíem dit que DISTINCT elimina duplicats?

Els ha eliminat. El que passa és que DISTINCT compara la fila completa, no columna per columna. (Espanya, València) i (Espanya, Madrid) són dues files diferents, encara que comparteixin el primer valor. Només s'elimina una fila si tots els seus valors coincideixen amb els d'una altra: (Espanya, València) apareixia quatre vegades a la taula i n'ha quedat una.

Pensa-hi així: DISTINCT mira la fila del resultat com si fos una tupla i es pregunta "ja he vist exactament aquesta tupla?".

Un altre exemple, aquesta vegada sobre el catàleg: quines combinacions de categoria i proveïdor existeixen?

Amb ORDER BY per poder llegir-ho (ho justifiquem a la secció 5):

12 combinacions a partir de 20 productes. Es llegeix molta informació de negoci en aquesta taula: la categoria 4 (Begudes) es proveeix de tres proveïdors diferents, mentre que la 6 (Complements) depèn d'un de sol, i aquest únic proveïdor —el 5, EcoNordic— és precisament el que està inactiu. Sense DISTINCT hauries hagut de llegir 20 files per arribar a la mateixa conclusió.

Si de debò vols "un país per fila i alguna cosa de les seves ciutats", DISTINCT no és l'eina: necessites agrupar, que és GROUP BY (lliçó 04-05). La diferència conceptual, per tenir-la clara des d'ara:

DISTINCT s'aplica després de la projecció del SELECT i abans d'ORDER BY. Això és coherent: només es poden comparar files duplicades un cop se sap quines columnes contenen.

D'aquí se'n dedueixen dues regles que veuràs en acció de seguida:

7 ciutats espanyoles. L'ordre és: FROM porta les 15 files → WHERE en deixa 11 → SELECT projecta ciutat → DISTINCT redueix a 7.

Ara l'ordre sí que està garantit (alfabètic). ORDER BY és la lliçó següent; aquí el fem servir només per fer llegibles els resultats.

Prova això:

El missatge és explícit i la raó és lògica, no arbitrària. Després del DISTINCT només queden tres files: Espanya, Portugal i França. La fila Espanya procedeix d'onze files originals amb onze ciutats diferents. Per quina de les onze caldria ordenar-la? La pregunta no té resposta, així que PostgreSQL es nega a inventar-se'n una.

La regla, memoritzable: amb SELECT DISTINCT, tot el que aparegui a ORDER BY ha d'aparèixer també a la llista del SELECT.

Si el que volies era ordenar els països per algun criteri derivat de les ciutats, necessites GROUP BY i una funció d'agregació (mòdul 4).

Un cas freqüent que també falla per això: ordenar per una columna que no projectes.

Mateix missatge. I si l'"arregles" afegint preu al SELECT, canvies la pregunta: passaries de "categories diferents" (6 files) a "combinacions diferents de categoria i preu" (20 files, perquè gairebé tots els preus són únics). Afegir columnes al SELECT debilita el DISTINCT.

Moltes vegades no vols la llista de valors diferents, sinó quants n'hi ha. Per a això es combina DISTINCT amb la funció d'agregació COUNT:

Fixa't en la diferència entre les tres variants de COUNT:

Aquí COUNT(ciutat) coincideix amb COUNT(*) perquè a BotigaVerda cap client no té la ciutat a nul, però la columna admet nuls i en una altra base de dades la diferència seria visible.

No hi aprofundim més: COUNT, SUM, AVG, MIN i MAX són la lliçó 04-04, i l'agrupació per categories, la 04-05. Ho deixem aquí simplement perquè és l'aplicació més freqüent de DISTINCT en el treball real d'anàlisi.

PostgreSQL afegeix una variant que no és a l'estàndard SQL i que és enormement útil: DISTINCT ON (columnes) conserva la primera fila de cada grup de valors, segons l'ordre que tu indiquis.

Problema: el producte més car de cada categoria.

Sis files, una per categoria, amb el producte més car de cadascuna. Això amb DISTINCT a seques és impossible.

Com funciona, pas a pas:

1. ORDER BY categoria_id, preu DESC ordena totes les files: primer agrupades per categoria, i dins de cada categoria, de més car a més barat.
2. DISTINCT ON (categoria_id) recorre aquest resultat ordenat i es queda amb la primera fila de cada valor de categoria_id, descartant la resta.

D'aquí en surt la regla d'or:

Les columnes de DISTINCT ON (...) han de ser les primeres de l'ORDER BY, i en el mateix ordre. Si no ho són, PostgreSQL dona error; i si l'ORDER BY no desempata bé el que ve després, la fila triada dins de cada grup és impredictible.

Si canvies preu DESC per preu, obtens el producte més barat de cada categoria:

El patró "la fila més X de cada grup" (l'última comanda de cada client, la ressenya més recent de cada producte, el preu més alt de cada categoria) és un dels més demanats al món real, i DISTINCT ON el resol en tres línies.

Portabilitat:

La forma portable amb funcions de finestra s'estudia a la lliçó 10-03, i és la que hauràs de fer servir si el teu SQL ha de funcionar fora de PostgreSQL. Mentre treballis amb PostgreSQL, DISTINCT ON és més curt i sol ser més ràpid.

DISTINCT no és gratis. Per saber si una fila està repetida, PostgreSQL ha de comparar totes les files entre si, i ho fa d'una d'aquestes dues maneres:

Amb 15 files és instantani. Amb deu milions de files i una columna de text llarg, un DISTINCT innecessari pot convertir una consulta de 50 ms en una de 30 segons. Ho podràs veure tu mateix amb EXPLAIN al mòdul 8.

I hi ha una cosa més important que el cost: un DISTINCT inesperat sol ser el símptoma d'una consulta mal plantejada, no la solució. El cas típic arriba al mòdul 3:

Aquesta consulta retorna 20 files i no 12, perquè la Lucía Martínez té tres comandes (1, 5 i 15) i hi apareix tres vegades. El reflex natural és afegir DISTINCT i quedar-se tranquil. Però el DISTINCT no arregla res: amaga el fet que la unió ha multiplicat les files. Si demà afegeixes una columna al SELECT —per exemple co.data_comanda—, les files es tornen a duplicar i el DISTINCT deixa de servir.

La llista de comprovació quan et descobreixis escrivint DISTINCT:

1. Hi ha duplicats de debò, o els està creant la meva consulta? Si és el segon cas, el problema és a la unió, no a la projecció.
2. El que vull és "valors diferents" o "un resultat per grup"? Si és el segon, és GROUP BY (04-05) o DISTINCT ON (secció 7).
3. Vull comprovar existència? Llavors l'eina correcta és EXISTS (lliçó 07-03), que no multiplica files i per tant no necessita deduplicar.
4. Estic deduplicant per columnes que no necessito? Treure del SELECT una columna innecessària pot fer que el DISTINCT sobri.

DISTINCT és perfectament legítim per al que hem fet en aquesta lliçó: preguntar "quins valors diferents hi ha en aquesta columna?". El que és sospitós és fer-lo servir com a pedaç.

• Creure que DISTINCT columna1, columna2 deduplica només per la primera. Deduplica per la combinació completa. És el malentès número u.
• Escriure DISTINCT(columna). Funciona, però fa pensar que DISTINCT és una funció que s'aplica a aquella columna. No ho és. Escriu DISTINCT columna1, columna2.
• Esperar que DISTINCT ordeni. No ordena. Si necessites ordre, ORDER BY.
• Ordenar per una columna que no és en un SELECT DISTINCT. ORDER BY expressions must appear in select list. I "arreglar-ho" afegint la columna canvia la pregunta.
• Afegir columnes i no adonar-se que el DISTINCT deixa de servir. Cada columna nova pot multiplicar les files del resultat.
• Fer servir DISTINCT per tapar duplicats creats per un JOIN. Corregeix la consulta, no el símptoma.
• Oblidar que els NULL s'agrupen. DISTINCT retorna una sola fila amb NULL, encara que n'hi hagi cent.
• Fer servir DISTINCT ON sense l'ORDER BY correcte. La fila que es conserva de cada grup és llavors impredictible: avui una, demà una altra.
• Consell: per comptar valors únics, COUNT(DISTINCT col) en comptes de portar-te la llista i comptar-la a mà.
• Consell: fes servir DISTINCT com a eina d'exploració. SELECT DISTINCT estat FROM comandes; és la manera més ràpida de saber quins valors conté realment una columna, inclosos els que no hi haurien de ser.
• Consell: si DISTINCT és lent, mira el pla. EXPLAIN (mòdul 8) et dirà si està ordenant a disc.

Màrqueting vol saber des de quines ciutats s'ha comprat a Portugal i França. Escriu una consulta que retorni les combinacions diferents de pais i ciutat dels clients que no siguin d'Espanya, ordenades per país i ciutat. Explica per què el resultat té el nombre de files que té.

Un company escriu aquesta consulta per saber quants mètodes de pagament diferents es fan servir i se sorprèn del resultat:

Explica què retorna realment, quantes files i per què no respon a la seva pregunta. Escriu després les dues consultes correctes: la que dona la llista de mètodes i la que dona el nombre.

Fent servir DISTINCT ON, obtén la comanda més recent de cada client que hagi comprat: client_id, id de la comanda, data_comanda i estat. Explica per què el resultat té 12 files i no 15, i quin paper hi juga l'ORDER BY.

Solució 1

4 files. El raonament segueix l'ordre lògic d'execució:

1. FROM clients → 15 files.
2. WHERE pais <> 'Espanya' → en queden 4 (els clients 7, 8, 9 i 10). Aquí no hi ha problema de nuls perquè pais és NOT NULL; si admetés nuls, aquests clients s'haurien perdut silenciosament, com vas veure a 02-03.
3. SELECT pais, ciutat → projecta dues columnes d'aquestes 4 files.
4. DISTINCT → busca combinacions repetides... i no n'hi ha cap, perquè els quatre clients estrangers viuen en quatre ciutats diferents.

És a dir, en aquest cas concret DISTINCT no elimina res. Això no el fa inútil: garanteix que si demà es registra un segon client a Lisboa, l'informe continuarà sent correcte.

Solució 2

La consulta del company retorna les combinacions diferents de mètode de pagament i estat:

10 files. targeta hi apareix quatre vegades, una per cada estat en què hi ha alguna comanda pagada amb targeta. No respon a "quants mètodes de pagament diferents hi ha" perquè DISTINCT deduplica la parella completa, i les parelles són diferents encara que comparteixin el mètode.

Les dues consultes correctes:

La moralitat: cada columna que afegeixes al SELECT pot multiplicar les files del resultat, perquè debilita la condició d'igualtat que fa servir DISTINCT. Abans d'afegir una columna a un SELECT DISTINCT, pregunta't si continua responent a la teva pregunta.

Solució 3

12 files i no 15. El motiu és als buits deliberats del conjunt de dades: els clients 13, 14 i 15 no han fet cap comanda, així que no apareixen a la taula comandes i no hi ha res a agrupar per a ells. Una consulta sobre comandes només pot parlar de clients que han demanat; per llistar també els que no van comprar mai cal combinar les dues taules amb un LEFT JOIN, que és exactament el contingut de la lliçó 03-03.

El paper de l'ORDER BY és doble i tots dos són imprescindibles:

• client_id primer perquè és la columna del DISTINCT ON: PostgreSQL exigeix que coincideixin, ja que necessita les files de cada client juntes per quedar-se'n una.
• data_comanda DESC després perquè determina quina de les files de cada client sobreviu: la primera del grup, és a dir, la de data més alta.

Si escrivissis ORDER BY client_id, data_comanda (ascendent), obtindries la primera comanda de cada client. I si ometessis la segona columna de l'ORDER BY, la fila triada dins de cada client seria la que el motor retornés primer, que pot canviar entre execucions.

Comprovació ràpida: la Lucía Martínez (client 1) té les comandes 1, 5 i 15, amb dates 2025-03-04, 2025-05-07 i 2025-12-02. N'ha sortit la 15, la més recent. Correcte.

Ja saps tractar els duplicats:

• Les files repetides no vénen de les dades, sinó de la projecció: en treure columnes, el que queda es repeteix. SQL treballa amb multiconjunts i no les elimina si no l'hi demanes.
• DISTINCT s'escriu just després de SELECT i elimina files repetides comparant la combinació completa de columnes projectades, no només la primera.
• S'aplica després de la projecció i abans d'ORDER BY, d'on surt la restricció que tot el que ordenis ha de ser al SELECT.
• Els NULL es col·lapsen en una sola fila, per excepció a la regla general dels nuls.
• COUNT(DISTINCT columna) compta valors únics i és l'aplicació més habitual en anàlisi de dades; les agregacions completes arriben al mòdul 4.
• DISTINCT ON (...) és una extensió de PostgreSQL que retorna la primera fila de cada grup segons l'ORDER BY, i resol en tres línies el patró "la fila més recent / més cara de cada X". Fora de PostgreSQL es fa amb funcions de finestra (mòdul 10).
• DISTINCT costa (ordenar o construir una taula hash) i, quan apareix per sorpresa, sol delatar una consulta mal plantejada més que resoldre un problema.

A la lliçó següent, Ordenar dades amb ORDER BY, deixaràs d'acceptar l'ordre que el motor tingui a bé donar-te. Veuràs com ordenar per una o diverses columnes, com es resolen els empats, com ordenar per àlies i per expressions calculades, on col·loca PostgreSQL els valors nuls (i per què MySQL els posa a l'altre extrem) i per què una lletra accentuada pot aparèixer on no esperes.