🔗 Le Query su Più Tabelle

🗄️ 1. Il Database di Esempio

Questa guida usa cinque tabelle, tutte con dati veri e completi. Sono le stesse tabelle della guida sulle subquery, con una differenza: ordini ha in più la colonna prodotto_id. Senza quella colonna non potremmo unire gli ordini ai prodotti, e metà di questa pagina non avrebbe niente da insegnare.

Il dataset contiene apposta tre casi "sporchi", cioè righe che non trovano la corrispondenza nell'altra tabella. Sono quelli che rendono interessante il LEFT JOIN: Gallo Pietro non ha mai ordinato, la Webcam HD non è mai stata ordinata. Il terzo caso — un reparto senza dipendenti — qui non c'è: tutti e quattro i reparti hanno almeno un dipendente. Lo incontrerai nella finestra esercizi, che genera ogni volta un dataset diverso.

Modello logico

In ogni tabella la chiave primaria è la prima colonna e le chiavi esterne le ultime: sono le colonne che collegano le tabelle, e in un JOIN sai già dove guardare.

Nota che clienti e dipendenti tengono cognome e nome in due attributi separati: sono due informazioni diverse, e un attributo solo non permetterebbe né di cercare per cognome né di ordinare l'elenco telefonico. Il nome completo, quando serve, si ottiene scrivendolo: CONCAT(cognome, ' ', nome). Nei modelli lo scriveremo come cognome nome.

I dati

Otto clienti, otto prodotti, dieci ordini, quattro reparti e otto dipendenti. Sono pochi, e per questo li puoi controllare a occhio: ogni risultato delle sezioni seguenti si può verificare riga per riga sulle tabelle qui sotto.

Chi compra, e da dove

L'id 8, Gallo Pietro, non compare in nessun ordine: è il cliente che useremo per spiegare il LEFT JOIN.

Gli ordini

Rossi Mario (id 1) ha tre ordini, Greco Sara (id 4) ne ha due. La colonna importo ripete il prezzo del prodotto ordinato: è una scorciatoia didattica, così i totali si leggono senza un altro JOIN.

Cosa si vende

Il prodotto 8, la Webcam HD, non compare in nessun ordine: è il caso speculare a Gallo Pietro.

Chi lavora dove

Tutti gli otto dipendenti hanno un reparto: Produzione ne ha tre, Vendite e Amministrazione due, Ricerca uno.

❓ 2. Perché Servono Più Tabelle

2.1 La domanda che non si può fare su una tabella sola

Proviamo a rispondere a una domanda fra le più frequenti negli esercizi di SQL: quanto ha ordinato Rossi Mario, e quando?

Cerchiamo Rossi Mario in clienti:

Ora sappiamo che Rossi Mario è il cliente numero 1. Ma nella tabella clienti non c'è nessuna traccia dei suoi ordini: la tabella ordini li elenca, però senza il nome del cliente, solo con il suo numero. Nessuna delle due tabelle, da sola, sa rispondere.

2.2 Perché non mettere tutto in una tabella sola?

Sarebbe più semplice, almeno all'inizio. Ma se copiassimo il nome del cliente dentro ogni riga di ordini, avremmo tre copie di "Rossi Mario". E se Rossi si trasferisse a Torino, dovremmo aggiornare la città in tutte le sue righe: se ne dimenticassimo una, il database si contraddirebbe da solo.

Questo problema ha un nome preciso, e l'abbiamo già visto: è la normalizzazione. Le tabelle sono separate perché ogni dato sia scritto una volta sola; il JOIN è il modo in cui le rimettiamo insieme quando serve.

Se vuoi rivedere il ragionamento, la guida sulle forme normali spiega perché una tabella sola non va bene e come si arriva a ottenerne cinque.

2.3 Ogni query legge da una sola tabella di righe

Questa è la regola che spiega perché il JOIN esiste, e vale la pena leggerla due volte. Il computer, quando esegue una SELECT, non legge mai da due tabelle insieme: legge sempre da una sola tabella di righe — un solo insieme di righe, una colonna per attributo. Quella tabella può essere una tabella vera del database, oppure — ed è il caso che ci interessa — il risultato temporaneo di una combinazione.

Da qui discendono tre conseguenze pratiche:

• SELECT sceglie colonne di quella tabella di righe;
• WHERE sceglie righe di quella tabella di righe;
• GROUP BY raggruppa righe di quella tabella di righe.

Se il dato che ti serve sta in due tabelle diverse, nessuna di queste tre clausole può prenderlo: prima devi costruire la tabella di righe che le mette insieme, e poi lavorarci. Il JOIN è esattamente l'operazione che la costruisce.

2.4 La tabella combinata, riga per riga

Vediamo il passo 1 su due tabelle. Vogliamo quanto ha speso ogni cliente: il nome sta in clienti, gli importi in ordini. Senza combinare niente, il computer ha a disposizione 8 righe da una parte e 10 dall'altra, e nessuna delle due ha sia il nome sia l'importo.

La combinazione parte da tutte le coppie possibili: ogni riga di clienti con ogni riga di ordini, cioè 8 × 10 = 80 righe. Fra queste ce ne sono di giuste e di sbagliate, mescolate. Ecco le prime cinque:

Il JOIN prende quelle 80 righe e tiene solo le combinazioni in cui la condizione di ON è vera, cioè quelle in cui ordini.cliente_id è uguale a clienti.id. Restano 10 righe: tante quante sono gli ordini, perché ogni ordine ha trovato il suo cliente. Questa è la tabella combinata su cui lavorerà tutto il resto della query:

Le colonne cliente e cliente_id dicono la stessa cosa: la seconda è la chiave esterna che ha reso possibile la combinazione, la prima è il nome che siamo andati a prendere nell'altra tabella.

Ora la domanda "quanto ha speso ogni cliente" è una normalissima domanda su una tabella sola: raggruppo per cliente e sommo importo. Il GROUP BY non sa niente di JOIN, e non deve saperlo: lavora sulle righe che ha.

Controlla il primo totale sulle righe della tabella combinata: Rossi Mario compare tre volte (ordini 1, 2 e 10), e 329 + 79 + 149 = 557. Il totale non è un calcolo "fra due tabelle": è la somma di tre importi, uno per ognuna delle sue tre righe nella tabella combinata.

2.5 Come si scrive un JOIN

Prima di scrivere bisogna decidere quali tabelle servono. Non è una scelta libera: dipende da quali dati chiede la traccia.

1. Quali dati devo mostrare? Ogni colonna che compare nella richiesta deve esistere in una tabella. Se la traccia chiede "il nome del cliente e l'importo dell'ordine", servono clienti (per il nome) e ordini (per l'importo).
2. Il numero minimo di tabelle: si prendono solo quelle che contengono almeno un dato richiesto, o che servono a collegare due tabelle altrimenti scollegate.
3. Come si collegano: fra due tabelle serve un percorso, cioè una chiave esterna che le metta in relazione. Se il percorso non è diretto, serve una tabella in più che faccia da ponte: è il caso della sezione 6, dove ordini collega clienti e prodotti.

Solo dopo si scrive il JOIN: le tabelle scelte vanno combinate in una tabella sola, con la condizione di ON che dice quali righe si corrispondono.

2.6 Quando il JOIN non serve

La chiave esterna è un attributo della tabella che la contiene. In ordini c'è cliente_id, in dipendenti c'è reparto_id: quei numeri si leggono già da lì, senza chiedere niente all'altra tabella.

Richiesta: per ogni ordine, il numero del cliente che lo ha fatto. Quel numero è ordini.cliente_id: è già in ordini.

Il JOIN serve quando dall'altra tabella si vuole un dato che nella prima non c'è: il nome del cliente, la sua città, il prezzo del prodotto. Se serve solo il numero, il numero è già lì.

E non è solo una questione di eleganza: il JOIN inutile può cambiare il risultato. Se una chiave esterna non trova la riga che dovrebbe indicare — succede quando il vincolo non è applicato, o quando il valore è NULL — il JOIN scarta quella riga, mentre ordini da sola la mostra:

🔗 3. JOIN su Due Tabelle

3.1 Il primo JOIN

Nella sezione 2.4 abbiamo costruito la tabella combinata e l'abbiamo usata per calcolare i totali. Qui rifacciamo lo stesso percorso guardando le righe una per una, per capire come nasce ogni riga di quella tabella.

Agganciamo ordini a clienti. La condizione è semplice: ogni riga di ordini deve trovare la riga di clienti che ha lo stesso id del proprio cliente_id. Le due colonne da confrontare si chiamano in modo diverso — id e cliente_id — ed è proprio il caso più comune.

Per capire cosa fa il JOIN basta seguire un ordine solo, il numero 4, dalla sua riga nella tabella ordini fino alla riga corrispondente del risultato. Sono le stesse righe delle tabelle della sezione 1, lette in ordine diverso.

La stessa cosa succede per tutti e dieci gli ordini: il JOIN li prende uno per uno e a ciascuno aggancia il suo cliente. Per questo Rossi Mario compare tre volte (ha tre ordini), Greco Sara due, e tutti gli altri una sola. Resta fuori una riga sola, quella di Gallo Pietro: nessun ordine ha cliente_id = 8. È il caso che analizziamo nella sezione 3.2.

Dieci righe, tante quante sono gli ordini: ogni ordine ha trovato il suo cliente, quindi nessuno è andato perso. Il nome del cliente si ripete — Rossi Mario compare tre volte — perché compare una volta per ordine, non una volta per cliente. È la quinta riga del risultato quella che abbiamo costruito qui sopra: Ferrari Luca · 329 · 2026-02-11.

3.2 Chi non ha ordini sparisce

Se chiediamo solo i nomi, il risultato ha ancora dieci righe ma solo sette nomi diversi:

Manca Gallo Pietro: la sua riga di clienti non ha trovato nessun ordine che la citasse, quindi è stata scartata, e con lei tutti i suoi dati. Una riga entra nel risultato solo se trova almeno una corrispondenza nell'altra tabella. Non è un errore: è il comportamento normale del JOIN.

3.3 I nomi di colonna uguali

Quando due tabelle hanno una colonna con lo stesso nome, per dire quale intendiamo dobbiamo scrivere il nome della tabella (o il suo alias) prima del punto. Fra clienti e ordini l'unica colonna omonima è id; appena si aggiunge una terza tabella i nomi in comune aumentano.

Qui nome esiste sia in clienti sia in prodotti: senza il prefisso c. o p. MariaDB non saprebbe quale delle due mostrare. Nella sezione 6 questo JOIN lo useremo per intero.

3.4 Errore: la colonna ambigua

👈 4. LEFT JOIN: le Righe che Mancano

4.1 Cosa cambia

Nella sezione 3 abbiamo visto che il JOIN butta via chi non ha corrispondenza. Ma spesso le informazioni che ci servono sono proprio quelle: quali clienti non hanno ancora ordinato, quali prodotti non sono mai stati venduti. Il LEFT JOIN nasce per questo. La differenza sta in una sola parola:

Sono 11 righe invece di 10. L'ultima è Gallo Pietro, che prima era sparito: c'è, ma con NULL al posto di importo e data_ordine. Non ha ordinato niente, quindi di importi non ce ne sono. Tutti gli altri hanno esattamente le stesse righe di prima.

4.2 Il trucco: LEFT JOIN + IS NULL

Ora che il LEFT JOIN ci restituisce anche chi non ha ordinato, basta chiedere esplicitamente le righe in cui l'altra tabella non ha dato niente:

Il filtro è o.id IS NULL: l'id di un ordine non è mai vuoto, quindi se è vuoto vuol dire che quell'ordine non esiste. Attenzione: si scrive IS NULL, non = NULL. Con il segno uguale non si ottiene niente, perché un valore ignoto non è uguale nemmeno a se stesso.

4.3 RIGHT JOIN: la stessa cosa, al contrario

RIGHT JOIN esiste ed è il simmetrico del LEFT JOIN: tiene tutte le righe della seconda tabella. Per ottenere lo stesso risultato basta scambiare l'ordine delle due tabelle e mettere RIGHT al posto di LEFT.

In pratica RIGHT JOIN si usa di rado: mettere per prima la tabella di cui vogliamo tutte le righe si legge molto meglio. Per questo LEFT JOIN è diventata l'abitudine standard per tenere le righe che mancano.

🏷️ 5. Gli Alias e il Self-Join

5.1 L'alias: un nome breve per la tabella

Quando la stessa colonna nome compare in più tabelle — clienti, prodotti, reparti, dipendenti — scrivere clienti.nome, prodotti.nome, reparti.nome diventa scomodo. Si assegna alla tabella un alias: un nome breve che si scrive dopo il nome della tabella e vale per tutto il resto della query.

Qui d è dipendenti e r è reparti. Due attenzioni:

• l'alias si usa con il punto: d.nome, non dipendenti.nome né dNome;
• l'AS nel SELECT è un'altra cosa: rinomina la colonna del risultato (dipendente, reparto), non la tabella. Serve perché in uscita ci sarebbero due colonne chiamate nome.

5.2 Lo stesso nome due volte: il self-join

Le due tabelle non devono per forza essere diverse. Per confrontare ogni dipendente con gli altri dello stesso reparto usiamo dipendenti due volte: la chiamiamo a per il primo e b per il secondo.

La condizione ha due parti: b.reparto_id = a.reparto_id dice che devono stare nello stesso reparto, e b.id > a.id fa sì che ogni coppia compaia una volta sola. Senza quel b.id > a.id, Ferrari Anna e Greco Marco comparirebbero due volte: una come "Ferrari con Greco" e una come "Greco con Ferrari". Ricerca non produce coppie, perché ha un solo dipendente.

🔗 6. JOIN su Tre Tabelle

Finora abbiamo unito due tabelle. Ma ordini si collega a due tabelle diverse: ha sia cliente_id sia prodotto_id. Per ottenere la scheda completa di un ordine — chi ha comprato, cosa ha comprato — servono tre tabelle.

6.1 Il passo intermedio: ordine e prodotto

Dieci righe come prima: nessun ordine punta a un prodotto inesistente, e il prodotto 8 (Webcam HD) non è mai stato ordinato — per questo non compare.

6.2 Tre tabelle: cliente, ordine e prodotto

Si aggiunge un secondo JOIN, con la sua condizione. Ogni riga si costruisce in cascata: prima clienti ⋈ ordini, poi il risultato si unisce a prodotti.

6.3 LEFT JOIN anche su tre tabelle

Il LEFT JOIN si può ripetere: ogni LEFT conserva tutte le righe della tabella che lo precede, anche quando nella successiva non c'è corrispondenza.

Gallo Pietro c'è, e sia il prodotto sia l'importo sono NULL: non ha ordinato niente, quindi non c'è nemmeno un prodotto da mostrare. Undici righe, come nel LEFT JOIN a due tabelle: il secondo LEFT non aggiunge righe, perché tutti gli ordini hanno il loro prodotto.

6.4 Errore: l'alias sbagliato

📊 7. JOIN con GROUP BY e le Funzioni Aggregate

Il GROUP BY funziona esattamente come su una tabella sola. Cambia solo che qui si raggruppa su colonne che vengono da tabelle diverse. Se hai letto la guida su GROUP BY hai già la teoria: qui vediamo la combinazione.

7.1 Raggruppare su una colonna dell'altra tabella

La domanda: quanto si è incassato per ogni categoria di prodotto? La categoria sta in prodotti, gli importi in ordini: per metterli insieme serve il JOIN.

Le tre categorie sono quelle dei prodotti ordinati: la Webcam HD è Elettronica, ma siccome nessuno l'ha ordinata non porta incassi e non crea nessun gruppo. Il totale complessivo 1482 è la somma di tutti e dieci gli ordini.

7.2 Filtrare i gruppi con HAVING

WHERE filtra le righe, HAVING filtra i gruppi già formati. Qui vogliamo solo i clienti che hanno speso più di 300: è una condizione su un totale, quindi va in HAVING.

7.3 Contare anche chi non ha ordinato

Qui c'è un trucco che vale la pena imparare. Se contiamo con COUNT(*), la riga in cui la seconda tabella manca viene contata come 1, perché la riga del cliente esiste lo stesso. Se invece contiamo una colonna della tabella agganciata, il NULL non viene contato:

Gallo Pietro ha numero_ordini = 0. Se avessimo scritto COUNT(*), la sua riga sarebbe questa:

Un ordine che non esiste contato come uno: esattamente l'errore da evitare.

📈 8. JOIN con ORDER BY e LIMIT

Quasi tutte le query che si fanno davvero su più tabelle sono report: un totale per cliente, ordinato dal migliore al peggiore, limitato alle prime righe. Si scrive come nella guida di base, ma il totale viene calcolato su dati che arrivano da due tabelle.

8.1 Il report completo

I clienti senza ordini sono spariti: il JOIN li ha scartati. Per includerli serve il LEFT JOIN — e allora Gallo Pietro comparirebbe con totale NULL, che in un report di soldi è meno utile di uno 0.

8.2 Il LIMIT: solo i primi tre

🧩 9. JOIN e Subquery: quando usare l'uno e quando l'altro

La guida sulle subquery ha spiegato che a una domanda si può spesso rispondere in due modi diversi. Vale anche per il JOIN, e saper scegliere fra i due è quello che distingue chi scrive SQL da chi lo imita.

E spesso la risposta è: entrambi nella stessa query. È quello che succede nelle prossime righe.

9.1 JOIN + subquery come soglia

Il caso più semplice: prendi le righe del JOIN, ma tieni solo quelle che superano la media calcolata su tutta la tabella.

La media degli importi è 148.2: le cinque righe qui sopra sono gli ordini che la superano. Il JOIN serve a ottenere il nome del cliente, la subquery a calcolare la media. Nessuno dei due fa il lavoro dell'altro.

9.2 Due modi per elencare i clienti che hanno ordinato

Prima con DISTINCT: il JOIN produce dieci righe, DISTINCT le riduce ai nomi diversi.

Poi con EXISTS, che chiede solo se esiste almeno una riga corrispondente:

Stesse 7 righe, due scritture diverse. Con molti ordini per cliente DISTINCT fa fatica, perché prima costruisce tutte le righe e poi scarta i duplicati; EXISTS si ferma al primo ordine trovato. Quando servono solo i nomi, e non i dati degli ordini, EXISTS è la forma più pulita.

9.3 Due modi per dire "mai ordinato"

Con il LEFT JOIN e un IS NULL troviamo i prodotti mai ordinati:

Con NOT EXISTS, invece, la domanda è diversa: quali prodotti non sono mai stati comprati da un cliente di Milano? Qui la subquery unisce ordini e clienti al suo interno:

Sono due domande diverse, non due scritture della stessa: la prima dà un prodotto, la seconda cinque. A Milano abitano Rossi Mario (che ha comprato Monitor, Tastiera e Sedia), Ferrari Luca (Monitor) e Gallo Pietro (che non ha mai ordinato): tutti gli altri prodotti non sono mai stati comprati da un milanese.

9.4 JOIN + GROUP BY + subquery in HAVING

La media degli stipendi serve a filtrare i gruppi, quindi va nel HAVING. La media la calcola la subquery.

La media aziendale è 44500; i quattro reparti hanno medie 37666.67, 51000, 38500 e 64000. Solo due la superano.

9.5 La subquery correlata: il JOIN che guarda se stesso

Questa è la forma più potente e quella che spaventa di più all'inizio. La subquery usa la colonna della tabella esterna (c.id), quindi va ricalcolata per ogni riga esterna: si chiama correlata.

Per ogni ordine la subquery chiede: è questo l'importo più alto fra gli ordini di questo cliente? La subquery guarda il cliente corrente — c.id: è questo che la rende correlata. L'alias o2 serve a distinguere la seconda copia di ordini dalla prima, esattamente come nel self-join della sezione 5.

9.6 Contare i clienti distinti

Un COUNT normale conta le righe, e un prodotto ordinato due volte dà 2. Se invece ci interessa quanti clienti diversi lo hanno ordinato, serve COUNT(DISTINCT ...).

Sono esattamente i tre prodotti ordinati due volte, da due clienti diversi. Se avessimo contato COUNT(o.cliente_id), il risultato sarebbe lo stesso qui — ma solo perché ogni prodotto è stato ordinato al massimo una volta per cliente.

⚠️ 10. USING e NATURAL JOIN: perché si evitano

MariaDB accetta due modi più brevi per scrivere un JOIN. Per completezza conviene conoscerli, ma in questa guida non li usiamo, e le righe seguenti spiegano perché.

Perché sono una scelta sconsigliata

La finestra esercizi di questa pagina rifiuta USING e NATURAL prima ancora di eseguirli, con un messaggio che rimanda a questa sezione: servono a farti vedere l'errore, non a fartelo scrivere.

⚠️ 11. Errori Comuni

11.1 Il filtro che cancella il LEFT JOIN

Questo è l'errore più insidioso di tutti, perché la query funziona: restituisce un risultato, solo che non è più quello che credevamo.

Vogliamo gli ordini da marzo in poi, mostrando anche i clienti che non ne hanno. Scriviamo:

Sono 5 righe: il WHERE ha eliminato tutti i clienti senza ordini, proprio come farebbe un JOIN. Il motivo è che la condizione su o.data_ordine viene valutata dopo il join, e per le righe senza corrispondenza vale NULL >= '2026-03-01', che non è vero: NULL confrontato con qualsiasi cosa dà un risultato sconosciuto, e lo sconosciuto in un WHERE vale come "falso".

Con questa correzione le righe diventano 8: i 5 ordini da marzo, più i 3 clienti che da marzo non hanno ordinato niente (Bianchi Giulia, Ferrari Luca e Gallo Pietro), che restano con NULL.

11.2 Il JOIN senza la condizione di ON

11.3 Il JOIN scritto dentro il WHERE

Molti libri di testo vecchi, e qualche esame, usano la forma senza la parola JOIN: una virgola nel FROM e la condizione nel WHERE. Funziona, ma non è un JOIN e con il LEFT JOIN non è nemmeno possibile scriverla così.

11.4 Contare le righe sbagliate

📝 12. Esercizi

Tredici esercizi sulle tabelle di questa guida, dal più semplice al più completo, tutti con la soluzione da aprire solo dopo aver provato. Per esercitarti su dataset sempre diversi usa la finestra esercizi: genera query su due o tre tabelle e ti dice se il risultato è quello giusto. Il pulsante è anche in fondo alla pagina, come nelle altre guide.

📌 13. Riepilogo Finale