El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

El RIGHT JOIN és el mirall exacte del LEFT JOIN: conserva totes les files de la taula dreta, casin o no amb l'esquerra. Conceptualment no aporta res de nou —de fet, en aquesta lliçó demostraràs que qualsevol RIGHT JOIN es pot reescriure com un LEFT JOIN—, i tanmateix mereix una lliçó pròpia per tres raons molt pràctiques: te'l trobaràs en codi aliè, hi ha situacions concretes en què apareix de manera natural, i barrejar-lo amb LEFT JOIN en una cadena de tres taules produeix consultes que gairebé ningú no sap llegir.

De passada, aquí apareixen per fi els cinc empleats de BotigaVerda que mai no han gestionat una comanda.

Contingut

La regla del RIGHT JOIN i el diagrama de conjunts
Tots els empleats amb les comandes que van gestionar
L'equivalència formal: A RIGHT JOIN B ≡ B LEFT JOIN A
Per què gairebé tothom prefereix LEFT
Quan un RIGHT JOIN sí que resulta natural
L'anti-join en versió RIGHT
El perill real: barrejar LEFT i RIGHT en una cadena
Suport per motor
Errors habituals i consells
Exercicis
Conclusió

La regla del `RIGHT JOIN` i el diagrama de conjunts

flowchart LR
    subgraph R[" "]
        direction LR
        A(("només a l'esquerra<br/>❌ fora"))
        I(("casen<br/>✅ resultat"))
        B(("només a la dreta<br/>✅ es conserva<br/>amb NULL a l'esquerra"))
    end
    style A fill:#f8f8f8,stroke:#bbb,stroke-dasharray: 4 4
    style I fill:#d9f0d9,stroke:#2b7a2b,stroke-width:3px
    style B fill:#d9f0d9,stroke:#2b7a2b,stroke-width:3px

Compara els tres diagrames del mòdul fins ara:

Tipus	Esquerra òrfena	Casen	Dreta òrfena
`INNER JOIN`	❌	✅	❌
`LEFT JOIN`	✅	✅	❌
`RIGHT JOIN`	❌	✅	✅

Tot el que has après a 03-03 s'hi aplica igual, amb els costats intercanviats:

RIGHT JOIN = RIGHT OUTER JOIN; la paraula OUTER és opcional.
Els NULL els fabrica el motor, ara a les columnes de la taula esquerra.
El pas 1d de l'ordre lògic reintrodueix les files dretes òrfenes dins del FROM, abans del WHERE.
I per tant una condició al WHERE sobre una columna de la taula esquerra degrada el RIGHT JOIN a INNER JOIN. És exactament el parany de 03-03, reflectit.

Tots els empleats amb les comandes que van gestionar

La pregunta: "dona'm els vuit empleats, amb les comandes que ha gestionat cadascun". Com que volem que apareguin tots els empleats, la taula que s'ha de conservar sencera és empleats. Si l'escrivim a la dreta, l'operador és RIGHT JOIN:

SELECT e.id AS empleat_id,
       e.nom || ' ' || e.cognoms AS empleat,
       e.carrec,
       co.id AS comanda_id,
       co.data_comanda,
       co.estat
FROM comandes AS co
RIGHT JOIN empleats AS e ON co.empleat_id = e.id
ORDER BY e.id, co.id;

empleat_id	empleat	carrec	comanda_id	data_comanda	estat
1	Rosa Alcázar Vives	Directora general	(null)	(null)	(null)
2	Andrés Company Talens	Responsable de vendes	(null)	(null)	(null)
3	Beatriz Nadal Ripoll	Responsable de logística	(null)	(null)	(null)
4	Óscar Peris Blasco	Comercial	2	2025-03-12	lliurat
4	Óscar Peris Blasco	Comercial	6	2025-05-23	cancellat
4	Óscar Peris Blasco	Comercial	10	2025-08-03	lliurat
4	Óscar Peris Blasco	Comercial	16	2025-12-19	enviat
5	Laia Puig Sanchis	Comercial	4	2025-04-19	lliurat
5	Laia Puig Sanchis	Comercial	8	2025-06-28	lliurat
5	Laia Puig Sanchis	Comercial	12	2025-10-01	lliurat
5	Laia Puig Sanchis	Comercial	18	2026-01-27	pagat
6	Marc Estévez Roig	Atenció al client	14	2025-11-14	lliurat
6	Marc Estévez Roig	Atenció al client	20	2026-02-21	pendent
7	Irene Salvador Mira	Operària de magatzem	(null)	(null)	(null)
8	Daniel Vercher Lluch	Analista de dades	(null)	(null)	(null)

15 files: les 10 comandes amb comercial més 5 empleats sense cap comanda assignada. El compte és el de 03-03, reflectit:

files del resultat = files que casen + files DRETES òrfenes
15 = 10 + 5

I el resultat es llegeix com un retrat de l'organigrama:

L'Óscar i la Laia són els dos comercials: quatre comandes cadascun.
En Marc, d'atenció al client, en va gestionar dues.
Irene Salvador Mira (operària de magatzem) i Daniel Vercher Lluch (analista de dades) no n'han gestionat cap, i és el que cal esperar: els seus càrrecs no venen.
La Rosa, l'Andrés i la Beatriz tampoc, per la mateixa raó: direcció i responsables d'àrea no atenen comandes directament.

Un INNER JOIN hauria retornat 10 files i tres empleats. Els altres cinc no haurien existit per a l'informe, i una consulta d'"activitat per empleat" que omet cinc de vuit persones no és un informe: és un problema.

L'equivalència formal: `A RIGHT JOIN B` ≡ `B LEFT JOIN A`

Escrivim la mateixa pregunta de l'altra manera: posant empleats a l'esquerra i fent servir LEFT JOIN.

SELECT e.id AS empleat_id,
       e.nom || ' ' || e.cognoms AS empleat,
       e.carrec,
       co.id AS comanda_id,
       co.data_comanda,
       co.estat
FROM empleats AS e
LEFT JOIN comandes AS co ON co.empleat_id = e.id
ORDER BY e.id, co.id;

empleat_id	empleat	carrec	comanda_id	data_comanda	estat
1	Rosa Alcázar Vives	Directora general	(null)	(null)	(null)
2	Andrés Company Talens	Responsable de vendes	(null)	(null)	(null)
3	Beatriz Nadal Ripoll	Responsable de logística	(null)	(null)	(null)
4	Óscar Peris Blasco	Comercial	2	2025-03-12	lliurat
4	Óscar Peris Blasco	Comercial	6	2025-05-23	cancellat
4	Óscar Peris Blasco	Comercial	10	2025-08-03	lliurat
4	Óscar Peris Blasco	Comercial	16	2025-12-19	enviat
5	Laia Puig Sanchis	Comercial	4	2025-04-19	lliurat
5	Laia Puig Sanchis	Comercial	8	2025-06-28	lliurat
5	Laia Puig Sanchis	Comercial	12	2025-10-01	lliurat
5	Laia Puig Sanchis	Comercial	18	2026-01-27	pagat
6	Marc Estévez Roig	Atenció al client	14	2025-11-14	lliurat
6	Marc Estévez Roig	Atenció al client	20	2026-02-21	pendent
7	Irene Salvador Mira	Operària de magatzem	(null)	(null)	(null)
8	Daniel Vercher Lluch	Analista de dades	(null)	(null)	(null)

Resultat idèntic, fila a fila. No s'assembla: és el mateix.

La regla general, que pots aplicar mecànicament:

A RIGHT JOIN B ON <cond> ≡ B LEFT JOIN A ON <cond>

Per convertir un RIGHT JOIN en LEFT JOIN: intercanvia l'ordre de les dues taules i canvia la paraula. La condició ON es queda exactament igual.

flowchart LR
    A["FROM comandes<br/>RIGHT JOIN empleats<br/>ON co.empleat_id = e.id"] -->|"intercanviar taules<br/>+ canviar la paraula"| B["FROM empleats<br/>LEFT JOIN comandes<br/>ON co.empleat_id = e.id"]

L'única cosa que pot canviar entre totes dues versions és l'ordre de les columnes si fessis servir SELECT *, i l'ordre de les files si no hi hagués ORDER BY. El conjunt de dades és el mateix.

D'aquí en surt una conclusió honesta: el RIGHT JOIN és prescindible. No existeix cap consulta que només es pugui escriure amb RIGHT JOIN. I tanmateix cal conèixer-lo, perquè existeix en el codi que heretaràs.

Per què gairebé tothom prefereix `LEFT`

Si són equivalents, per què pràcticament totes les guies d'estil professionals recomanen LEFT?

Motiu	Explicació
Es llegeix en l'ordre en què es pensa	"Tots els empleats, amb les seves comandes" comença per `empleats`. A la versió `RIGHT`, la taula protagonista està enterrada a l'última línia
La taula principal és la primera	El lector identifica d'un cop d'ull la granularitat del resultat: una fila per... el que sigui que hi hagi al `FROM`
Consistència en cadenes llargues	Amb cinc taules, si totes les unions externes són `LEFT`, el `FROM` es llegeix de dalt a baix com un camí. Si alternes, cal anar i tornar
Menys càrrega mental en depurar	Quan alguna cosa falla, buscar "quina taula conservo sencera" és immediat si sempre és la primera
És el que espera l'equip	El `LEFT JOIN` és aclaparadorament majoritari a la pràctica. Un `RIGHT JOIN` fa que qui revisa el codi s'aturi a comprovar si és intencionat

Convenció del curs: escriurem LEFT JOIN sempre que puguem triar, i col·locarem com a primera taula del FROM aquella les files de la qual han d'aparèixer totes. El RIGHT JOIN apareix en aquest curs perquè el sàpigues llegir i reescriure, no com a estil recomanat.

Quan un `RIGHT JOIN` sí que resulta natural

Dit això, hi ha dues situacions en què escriure un RIGHT JOIN és raonable.

5.1. Afegir una taula al final d'una consulta ja escrita

Imagina que tens aquesta consulta funcionant en producció, amb el seu SELECT de dotze columnes i els seus filtres:

SELECT lc.id, lc.quantitat, lc.preu_unitari, ...
FROM linies_comanda AS lc
JOIN comandes AS co ON lc.comanda_id = co.id
WHERE co.data_comanda >= DATE '2025-01-01'
  AND co.data_comanda <  DATE '2026-01-01';

I et demanen que l'informe inclogui també els productes que no es van vendre. La reescriptura "correcta" obliga a posar productes com a primera taula i reordenar tot el FROM. Afegir una línia al final és molt menys invasiu:

...
RIGHT JOIN productes AS p ON lc.producte_id = p.id

És un ús legítim, amb una condició: documenta'l. Un comentari d'una línia (-- RIGHT per conservar els productes sense vendes) evita que el lector següent pensi que és una errada.

5.2. Traduir un requisit escrit de manera mecànica

Quan el requisit arriba redactat com a "les línies de comanda, i a més tots els productes encara que no tinguin línies", escriure-ho en aquest mateix ordre és el més fidel:

SELECT p.id AS producte_id,
       p.nom AS producte,
       lc.id AS linia_id,
       lc.quantitat
FROM linies_comanda AS lc
RIGHT JOIN productes AS p ON lc.producte_id = p.id
ORDER BY p.id, lc.id;

Retorna 50 files: les 47 línies més els 3 productes mai venuts. És exactament el mateix resultat que el productes LEFT JOIN linies_comanda de 03-03.

Tot i així, la pràctica habitual és traduir primer el requisit i reescriure'l després com a LEFT abans de pujar-lo al repositori.

L'anti-join en versió `RIGHT`

El patró de 03-03 funciona igual, canviant quin costat es comprova. Per respondre a "quins empleats no han gestionat mai una comanda?":

SELECT e.id AS empleat_id,
       e.nom || ' ' || e.cognoms AS empleat,
       e.carrec,
       e.data_contractacio
FROM comandes AS co
RIGHT JOIN empleats AS e ON co.empleat_id = e.id
WHERE co.id IS NULL
ORDER BY e.id;

empleat_id	empleat	carrec	data_contractacio
1	Rosa Alcázar Vives	Directora general	2024-09-01
2	Andrés Company Talens	Responsable de vendes	2024-10-15
3	Beatriz Nadal Ripoll	Responsable de logística	2024-11-02
7	Irene Salvador Mira	Operària de magatzem	2025-04-07
8	Daniel Vercher Lluch	Analista de dades	2025-06-16

5 files. I la mateixa consulta escrita com a LEFT, que és com l'escriuríem al curs:

-- ✅ Preferida
SELECT e.id AS empleat_id,
       e.nom || ' ' || e.cognoms AS empleat,
       e.carrec,
       e.data_contractacio
FROM empleats AS e
LEFT JOIN comandes AS co ON co.empleat_id = e.id
WHERE co.id IS NULL
ORDER BY e.id;

Resultat idèntic. Fixa't en el detall que es manté entre les dues versions: la columna comprovada amb IS NULL és sempre la clau primària de la taula opcional (co.id), no la del costat que es conserva. La paraula LEFT o RIGHT canvia; la lògica de l'anti-join, no.

Interpretació del resultat: que cinc dels vuit empleats no tinguin comandes no és un problema de dades. Només dos comercials i una persona d'atenció al client gestionen vendes; la direcció, la logística i l'anàlisi de dades, no. És una consulta que confirma el model de negoci, no que el contradigui.

El perill real: barrejar `LEFT` i `RIGHT` en una cadena

Aquí hi ha la raó de pes per tenir disciplina d'estil. Considera aquesta consulta, escrita per algú que volia "tots els clients, amb les seves comandes i l'empleat de cada comanda":

-- ⚠️ INCORRECTA: no fa el que el seu autor es pensa
SELECT c.nom AS client,
       co.id AS comanda_id,
       e.nom AS empleat
FROM clients AS c
LEFT JOIN comandes AS co ON co.client_id = c.id
RIGHT JOIN empleats AS e ON co.empleat_id = e.id
ORDER BY e.id, co.id;

client	comanda_id	empleat
(null)	(null)	Rosa
(null)	(null)	Andrés
(null)	(null)	Beatriz
Carlos	2	Óscar
Ana	6	Óscar
Camille	10	Óscar
Javier	16	Óscar
Javier	4	Laia
Sofia	8	Laia
Julien	12	Laia
Ana	18	Laia
Diego	14	Marc
Camille	20	Marc
(null)	(null)	Irene
(null)	(null)	Daniel

15 files, i ni rastre de la Núria, l'Hugo o la Inés. El LEFT JOIN que es va escriure per conservar-los no ha servit de res.

Per què

Els JOIN es resolen d'esquerra a dreta:

flowchart TD
    A["clients (15)"] --> B["clients LEFT JOIN comandes<br/>= 23 files<br/>(inclou la Núria, l'Hugo, la Inés)"]
    B --> C["aquest resultat de 23 files<br/>RIGHT JOIN empleats"]
    C --> D["RIGHT conserva TOTS els empleats<br/>però descarta les files esquerres<br/>sense empleat que casi"]
    D --> E["15 files:<br/>10 emparellaments + 5 empleats sols<br/>❌ la Núria, l'Hugo i la Inés desapareixen"]

El RIGHT JOIN conserva enterament la taula dreta (empleats) i descarta les files esquerres que no casen. I les files de la Núria, l'Hugo i la Inés tenen co.empleat_id = NULL, així que no casen amb cap empleat i se'n van. Igual que les 10 files de comandes web.

És la mateixa lògica del "LEFT seguit d'INNER" de 03-03, però disfressada: aquí el RIGHT actua sobre l'acumulació de tot l'anterior, no sobre la taula que té al costat.

La reescriptura

La consulta de dalt, en realitat, respon a "tots els empleats amb les comandes que van gestionar i els seus clients". Escrita només amb LEFT queda transparent:

-- ✅ CORRECTA: el mateix, llegible
SELECT c.nom AS client,
       co.id AS comanda_id,
       e.nom AS empleat
FROM empleats AS e
LEFT JOIN comandes AS co ON co.empleat_id = e.id
LEFT JOIN clients  AS c  ON co.client_id  = c.id
ORDER BY e.id, co.id;

Les mateixes 15 files. Ara el FROM es llegeix de dalt a baix: empleats → les seves comandes → el client de cada comanda, i la primera taula anuncia sense ambigüitat que l'informe té una fila per empleat com a mínim.

I si el que de debò volia l'autor era conservar els tres clients sense comandes, la consulta és una altra:

-- ✅ CORRECTA per a "tots els clients"
FROM clients AS c
LEFT JOIN comandes AS co ON co.client_id  = c.id
LEFT JOIN empleats AS e  ON co.empleat_id = e.id

Que retorna 23 files, com vas veure a 03-03.

Regla d'or: en una cadena de tres o més taules, no barregis LEFT i RIGHT. Tria el costat que vols conservar, posa'l com a primera taula del FROM i fes servir només LEFT JOIN a partir d'aquí. Una consulta amb LEFT i RIGHT alternats és correcta per al motor i il·legible per a les persones, que és la pitjor combinació possible.

Comparativa de les tres versions sobre les mateixes tres taules:

Consulta	Files	Què conserva
`clients LEFT comandes RIGHT empleats`	15	Tots els empleats. Els clients sense comanda es perden
`empleats LEFT comandes LEFT clients`	15	Tots els empleats (idèntica a l'anterior, llegible)
`clients LEFT comandes LEFT empleats`	23	Tots els clients, inclosos els tres sense comandes

Suport per motor

Motor	`RIGHT JOIN`	Nota
PostgreSQL	✅ De sempre	Sense restriccions
MySQL / MariaDB	✅	Sense restriccions
SQL Server	✅	La sintaxi antiga `*=` està eliminada des del 2012
Oracle	✅	La sintaxi antiga `(+)` continua existint però està desaconsellada
SQLite	✅ només des de la 3.39 (juny del 2022)	Abans calia reescriure'l com a `LEFT JOIN`

Aquest últim cas és un argument addicional a favor del LEFT JOIN: un LEFT JOIN funciona en qualsevol motor i en qualsevol versió, inclosos els SQLite incrustats en aplicacions mòbils antigues. Escriure sempre LEFT és també una decisió de portabilitat.

Nota de dialecte: a Oracle antic, A RIGHT JOIN B s'escrivia posant el (+) al costat contrari al que es conserva: WHERE a.id(+) = b.id. Aquesta notació és una font inesgotable d'errors i no s'ha de fer servir en codi nou, encara que la trobaràs en sistemes heretats.

Errors habituals i consells

Confondre quin costat es conserva. A A RIGHT JOIN B, el que es conserva sencer és B, la taula que va després de la paraula. És el contrari del que suggereix la lectura d'esquerra a dreta.
Barrejar LEFT i RIGHT a la mateixa cadena. El RIGHT actua sobre tot l'acumulat fins a aquell punt, no sobre la taula contigua, i pot anul·lar en silenci un LEFT anterior.
Posar una condició sobre la taula esquerra al WHERE d'un RIGHT JOIN. El degrada a INNER JOIN, exactament igual que a 03-03 però amb els costats canviats.
Fer l'anti-join contra la columna equivocada. En un RIGHT JOIN, la columna que es comprova amb IS NULL és la clau primària de la taula esquerra (l'opcional), no la de la que es conserva.
Fer servir RIGHT JOIN sense comentar-ne el perquè. Qui revisi el codi assumirà que és un descuit. Un comentari d'una línia ho resol.
Escriure RIGHT JOIN en codi que ha de córrer sobre SQLite antic. No existeix abans de la versió 3.39.
Consell: aprèn la conversió mecànica. Intercanvia les dues taules, canvia RIGHT per LEFT, deixa l'ON intacte. Funciona sempre i és la manera més ràpida d'entendre un RIGHT JOIN aliè.
Consell: en revisar codi, reescriu mentalment tot RIGHT com a LEFT abans de raonar-hi. És més ràpid que intentar seguir la lògica invertida.
Consell: decideix el costat protagonista abans d'escriure una línia. "Quin substantiu ha de sortir complet a l'informe?" Aquella taula va primera, i tota la resta és LEFT JOIN.

Exercicis

Exercici 1

Escriu amb RIGHT JOIN la consulta que retorna tots els productes amb les línies de venda que hagin tingut: id i nom del producte, id de la línia i quantitat. Després reescriu-la amb LEFT JOIN i comprova que el resultat és idèntic.

Quantes files retorna i d'on surt aquest número?

Exercici 2

Recursos humans vol el llistat d'empleats que mai no han gestionat una comanda, amb el seu càrrec, la seva ciutat i el nom de pila del seu cap.

Escriu-ho amb RIGHT JOIN per a la part de les comandes.
Reescriu-ho sencer amb LEFT JOIN.
Explica per què el JOIN amb la taula de caps ha de ser LEFT i no INNER.

(Pista: unir empleats amb si mateixa per obtenir el cap és un SELF JOIN; s'explica a fons a 03-06, però aquí n'hi ha prou de fer servir dos àlies diferents de la mateixa taula.)

Exercici 3

Analitza aquesta consulta sense executar-la:

SELECT p.nom AS producte, lc.id AS linia_id, cat.nom AS categoria
FROM linies_comanda AS lc
RIGHT JOIN productes  AS p   ON lc.producte_id = p.id
LEFT  JOIN categories AS cat ON p.categoria_id = cat.id
WHERE lc.quantitat > 2;

Quina creus que era la intenció de qui la va escriure?
Què fa realment? Apareixen els productes mai venuts?
Corregeix-la perquè retorni tots els productes, mostrant només les línies de més de 2 unitats i NULL per a la resta.

Solucions

Solució 1

Amb RIGHT JOIN:

SELECT p.id AS producte_id,
       p.nom AS producte,
       lc.id AS linia_id,
       lc.quantitat
FROM linies_comanda AS lc
RIGHT JOIN productes AS p ON lc.producte_id = p.id
ORDER BY p.id, lc.id;

Amb LEFT JOIN (la forma preferida):

SELECT p.id AS producte_id,
       p.nom AS producte,
       lc.id AS linia_id,
       lc.quantitat
FROM productes AS p
LEFT JOIN linies_comanda AS lc ON lc.producte_id = p.id
ORDER BY p.id, lc.id;

Totes dues retornen 50 files:

47 línies de comanda que casen
+ 3 productes sense cap línia (13, 19 i 20)
= 50

Les tres files òrfenes són:

producte_id	producte	linia_id	quantitat
13	Espelmes de cera de soja (pack 2)	(null)	(null)
19	Desodorant natural en barra 50 g	(null)	(null)
20	Càpsules d'espirulina 120 u	(null)	(null)

La transformació aplicada és la mecànica de la secció 3: s'intercanvien linies_comanda i productes, RIGHT passa a LEFT, i la condició ON lc.producte_id = p.id no es toca.

Solució 2

1. Amb RIGHT JOIN a la part de comandes:

SELECT e.id AS empleat_id,
       e.nom || ' ' || e.cognoms AS empleat,
       e.carrec,
       e.ciutat,
       cap.nom AS cap
FROM comandes AS co
RIGHT JOIN empleats AS e   ON co.empleat_id = e.id
LEFT  JOIN empleats AS cap ON e.cap_id = cap.id
WHERE co.id IS NULL
ORDER BY e.id;

2. Reescrit només amb LEFT:

-- ✅ Preferida
SELECT e.id AS empleat_id,
       e.nom || ' ' || e.cognoms AS empleat,
       e.carrec,
       e.ciutat,
       cap.nom AS cap
FROM empleats AS e
LEFT JOIN comandes AS co  ON co.empleat_id = e.id
LEFT JOIN empleats AS cap ON e.cap_id = cap.id
WHERE co.id IS NULL
ORDER BY e.id;

empleat_id	empleat	carrec	ciutat	cap
1	Rosa Alcázar Vives	Directora general	València	(null)
2	Andrés Company Talens	Responsable de vendes	València	Rosa
3	Beatriz Nadal Ripoll	Responsable de logística	València	Rosa
7	Irene Salvador Mira	Operària de magatzem	València	Beatriz
8	Daniel Vercher Lluch	Analista de dades	València	Rosa

5 files.

3. Per què el JOIN amb els caps ha de ser LEFT: perquè Rosa Alcázar Vives no té cap (cap_id IS NULL, és la directora general). Amb un INNER JOIN contra empleats AS cap, la seva fila no trobaria parella i desapareixeria del resultat, que passaria de 5 a 4 files. És exactament el cas del "LEFT seguit d'INNER" de 03-03: un sol INNER a la cadena elimina la fila que més interessa. La jerarquia completa d'empleats s'estudia a 03-06.

Solució 3

1. La intenció era, amb tota probabilitat, "tots els productes amb les seves línies de més de 2 unitats", conservant el catàleg sencer gràcies al RIGHT JOIN.

2. Què fa realment. La condició lc.quantitat > 2 és al WHERE i afecta una columna de la taula esquerra, que és justament l'opcional en un RIGHT JOIN. Els tres productes mai venuts arriben al WHERE amb lc.quantitat = NULL, i NULL > 2 no és TRUE. Desapareixen. El RIGHT JOIN es degrada a INNER JOIN i la consulta retorna només les línies de més de 2 unitats amb el seu producte: no apareix cap producte mai venut.

És el parany de 03-03 vist al mirall: allà la condició perillosa era sobre la taula dreta d'un LEFT; aquí, sobre l'esquerra d'un RIGHT.

3. Correcció. Cal moure la condició a l'ON i, ja posats, reescriure-ho tot amb LEFT posant productes com a taula protagonista:

-- ✅ CORRECTA
SELECT p.nom   AS producte,
       cat.nom AS categoria,
       lc.id   AS linia_id,
       lc.quantitat
FROM productes AS p
LEFT JOIN categories     AS cat ON p.categoria_id = cat.id
LEFT JOIN linies_comanda AS lc
       ON lc.producte_id = p.id
      AND lc.quantitat > 2
ORDER BY p.id, lc.id;

Ara els 20 productes apareixen sempre; els que no tinguin cap línia de més de 2 unitats mostren *(null)* a linia_id i quantitat. Observa a més que el JOIN amb categories s'ha escrit com a LEFT per prudència i coherència d'estil: aquí no canvia res perquè tot producte té categoria, però manté la regla d'"oberta una branca amb LEFT, continua amb LEFT".

Conclusió

El RIGHT JOIN ja no et sorprendrà en cap codi:

Conserva totes les files de la taula dreta, la que va després de la paraula JOIN, omplint amb NULL les columnes de l'esquerra. RIGHT JOIN = RIGHT OUTER JOIN.
Has vist per fi els cinc empleats sense comandes: la Rosa, l'Andrés, la Beatriz, la Irene i en Daniel. 15 files enfront de les 10 de l'INNER JOIN.
Coneixes l'equivalència formal: A RIGHT JOIN B ≡ B LEFT JOIN A. Intercanvia les taules, canvia la paraula, deixa l'ON intacte. Cap consulta no necessita un RIGHT JOIN.
Saps per què es prefereix LEFT: la taula protagonista es llegeix primer, les cadenes llargues es llegeixen de dalt a baix, i funciona en tots els motors i versions (SQLite no admet RIGHT fins a la 3.39).
Saps quan un RIGHT és defensable: en afegir una taula al final d'una consulta ja escrita o en traduir un requisit literalment. Sempre amb un comentari que ho justifiqui.
L'anti-join en versió RIGHT funciona igual, comprovant amb IS NULL la clau primària de la taula esquerra.
I sobretot: no barregis LEFT i RIGHT en una cadena. El RIGHT actua sobre tot l'acumulat i pot anul·lar en silenci un LEFT anterior, com a l'exemple on la Núria, l'Hugo i la Inés desapareixien tot i el LEFT JOIN escrit per conservar-los.

A la lliçó següent, FULL OUTER JOIN, tancarem la família dels joins externs amb el que conserva els orfes de tots dos costats alhora. Veuràs per què en un esquema amb integritat referencial —com el de BotigaVerda— gairebé mai no hi ha orfes als dos costats, i per què el seu veritable terreny de joc és la conciliació de dues fonts de dades independents: un catàleg contra un fitxer de vendes extern, un inventari contra un sistema comptable.

RIGHT JOIN

Contingut

La regla del `RIGHT JOIN` i el diagrama de conjunts

Tots els empleats amb les comandes que van gestionar

L'equivalència formal: `A RIGHT JOIN B` ≡ `B LEFT JOIN A`

Per què gairebé tothom prefereix `LEFT`

Quan un `RIGHT JOIN` sí que resulta natural

5.1. Afegir una taula al final d'una consulta ja escrita

5.2. Traduir un requisit escrit de manera mecànica

L'anti-join en versió `RIGHT`

El perill real: barrejar `LEFT` i `RIGHT` en una cadena

Per què

La reescriptura

Suport per motor

Errors habituals i consells

Exercicis

Exercici 1

Exercici 2

Exercici 3

Solucions

Conclusió

Curs de SQL

Mòdul 1: Introducció a SQL

Mòdul 2: Consultes bàsiques de SQL

Mòdul 3: Treballar amb múltiples taules

Mòdul 4: Filtratge avançat de dades

Mòdul 5: Manipulació de dades

Mòdul 6: Funcions avançades de SQL

Mòdul 7: Subconsultes i consultes imbricades

Mòdul 8: Índexs i optimització del rendiment

Mòdul 9: Transaccions i concurrència

Mòdul 10: Temes avançats

Mòdul 11: SQL a la pràctica

Mòdul 12: Projecte final

RIGHT JOIN

Contingut

La regla del RIGHT JOIN i el diagrama de conjunts

Tots els empleats amb les comandes que van gestionar

L'equivalència formal: A RIGHT JOIN B ≡ B LEFT JOIN A

Per què gairebé tothom prefereix LEFT

Quan un RIGHT JOIN sí que resulta natural

5.1. Afegir una taula al final d'una consulta ja escrita

5.2. Traduir un requisit escrit de manera mecànica

L'anti-join en versió RIGHT

El perill real: barrejar LEFT i RIGHT en una cadena

Per què

La reescriptura

Suport per motor

Errors habituals i consells

Exercicis

Exercici 1

Exercici 2

Exercici 3

Solucions

Conclusió

Curs de SQL

Mòdul 1: Introducció a SQL

Mòdul 2: Consultes bàsiques de SQL

Mòdul 3: Treballar amb múltiples taules

Mòdul 4: Filtratge avançat de dades

Mòdul 5: Manipulació de dades

Mòdul 6: Funcions avançades de SQL

Mòdul 7: Subconsultes i consultes imbricades

Mòdul 8: Índexs i optimització del rendiment

Mòdul 9: Transaccions i concurrència

Mòdul 10: Temes avançats

Mòdul 11: SQL a la pràctica

Mòdul 12: Projecte final

La regla del `RIGHT JOIN` i el diagrama de conjunts

L'equivalència formal: `A RIGHT JOIN B` ≡ `B LEFT JOIN A`

Per què gairebé tothom prefereix `LEFT`

Quan un `RIGHT JOIN` sí que resulta natural

L'anti-join en versió `RIGHT`

El perill real: barrejar `LEFT` i `RIGHT` en una cadena