JOIN-uri SQL explicate prin cazuri reale de business

JOIN-urile par teorie de manual. În realitate, ele decid dacă raportul tău arată cifrele reale sau o variantă inventată subtil. Iată ce contează.

JOIN-uri SQL — INNER, LEFT, RIGHT, FULL, CROSS — exemple business din retail, finance și SaaS

Daniel Pisău

septembrie 8, 2026

SQL & Databases

Un analyst senior privește două rapoarte despre vânzări pe luna trecută. Unul spune 1.247.000 lei. Altul spune 1.318.000 lei. Aceeași sursă, aceeași perioadă, două rezultate. Diferența: un LEFT JOIN scris INNER JOIN într-una dintre query-uri.

JOIN-urile par teorie de manual. În practică, sunt cel mai des-întâlnit punct unde rapoartele BI încep să mintă subtil. Nu cad pipeline-urile. Nu apare eroare. Doar cifrele nu se potrivesc.

Articolul ăsta nu e un tutorial pentru începători. Pentru cei care n-au mai văzut SQL deloc, există documentație la Microsoft Docs. Aici discutăm JOIN SQL business — cum se folosesc realist, cu cazuri concrete din retail, finance și SaaS.

JOIN SQL: Recap rapid: ce face fiecare JOIN

Cinci tipuri principale:

INNER JOIN — păstrează doar rândurile care au match în ambele tabele.
LEFT JOIN — păstrează tot din tabelul stâng, NULL acolo unde nu e match.
RIGHT JOIN — invers față de LEFT. Rar folosit în practică (oamenii rescriu ca LEFT).
FULL OUTER JOIN — păstrează tot din ambele tabele, NULL unde nu e match.
CROSS JOIN — produsul cartezian. Fiecare rând din A combinat cu fiecare rând din B.

Plus o variantă pe care o vezi rar dar e utilă: SEMI JOIN și ANTI JOIN — exprimate prin EXISTS și NOT EXISTS. Vorbim despre ele mai jos.

Restul articolului discută cazuri reale. Sintaxa apare în context.

Caz 1: vânzări și clienți — INNER vs LEFT

O companie de retail B2B vrea să raporteze vânzările lunare cu numele clienților. Două tabele:

orders — id, customer_id, order_date, total_amount.
customers — id, name, country, segment.

Prima variantă, scrisă de junior:

SELECT
  c.name,
  c.country,
  SUM(o.total_amount) AS total_vanzari
FROM orders o
INNER JOIN customers c ON o.customer_id = c.id
WHERE o.order_date BETWEEN '2026-12-01' AND '2026-12-31'
GROUP BY c.name, c.country;

Pare corect. Totalul ar trebui să iasă. În realitate, problema apare când în tabelul orders există comenzi cu customer_id setat la null sau către un client șters din customers. INNER JOIN-ul le exclude. Rezultatul: totalul raportat e mai mic decât totalul real al vânzărilor.

Cum descoperi că ai problema? Compară totalul din raport cu un SUM simplu pe orders. Dacă diferă, ai pierdut rânduri pe JOIN.

Soluția în business depinde de ce vrei să raportezi. Dacă vrei vânzări către clienți activi, INNER JOIN e corect, dar trebuie să raportezi explicit „vânzări către clienți activi” și să raportezi separat vânzările orfane.

Dacă vrei vânzări totale, indiferent de status client, LEFT JOIN din orders către customers:

SELECT
  COALESCE(c.name, 'Client necunoscut') AS name,
  COALESCE(c.country, 'N/A') AS country,
  SUM(o.total_amount) AS total_vanzari
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.id
WHERE o.order_date BETWEEN '2026-12-01' AND '2026-12-31'
GROUP BY c.name, c.country;

Aici COALESCE protejează raportul de NULL-uri urâte. Plus că forțează discuția cu echipa: de ce avem clienți „necunoscuți”?

Regula pe care echipele mature o aplică: în query-urile financiare, JOIN-ul implicit ar trebui să fie LEFT, cu validare explicită că nu pierzi rânduri. INNER doar când vrei să excluzi conștient.

Caz 2: produse fără vânzări — LEFT JOIN inversat

Aceeași companie vrea să identifice produse care nu s-au vândut în ultimele 90 de zile. Tabele:

products — id, name, category, is_active.
order_lines — id, order_id, product_id, quantity, unit_price.

Întrebarea sună invers — vrei rândurile din products care NU au match în order_lines pe perioada respectivă.

SELECT
  p.id,
  p.name,
  p.category
FROM products p
LEFT JOIN order_lines ol ON p.id = ol.product_id
  AND ol.created_at >= CURRENT_DATE - INTERVAL '90 days'
WHERE p.is_active = TRUE
  AND ol.id IS NULL;

Două subtilități aici.

Prima: condiția de dată trebuie să fie în ON, nu în WHERE. Dacă o pui în WHERE, transformi LEFT JOIN-ul în INNER JOIN efectiv — pentru că eliminăm rândurile unde ol.created_at e NULL.

A doua: ol.id IS NULL e felul standard de a exprima „nu a fost match”. Funcționează pe orice coloană din tabelul drept care e NOT NULL în mod normal.

Asta e un anti-pattern care apare des în interviuri și produce bug-uri reale. Diferența dintre filtru pe ON și pe WHERE pentru LEFT JOIN e cea mai comună greșeală conceptuală în SQL.

Caz 3: abonamente SaaS și plăți — multiple LEFT JOIN-uri

O companie SaaS B2B vrea un raport săptămânal cu starea abonamentelor: contract activ, ultima plată, MRR curent, manager de cont.

Tabele relevante:

subscriptions — id, customer_id, plan_id, status, started_at.
payments — id, subscription_id, amount, paid_at.
customers — id, name, account_manager_id.
users — id, full_name (manageri de cont).
plans — id, name, monthly_price.

Query-ul are 4 JOIN-uri. Iată varianta funcțională:

SELECT
  c.name AS customer,
  pl.name AS plan,
  pl.monthly_price AS mrr,
  s.status,
  s.started_at,
  MAX(p.paid_at) AS last_payment,
  u.full_name AS account_manager
FROM subscriptions s
INNER JOIN customers c ON s.customer_id = c.id
INNER JOIN plans pl ON s.plan_id = pl.id
LEFT JOIN payments p ON p.subscription_id = s.id
LEFT JOIN users u ON c.account_manager_id = u.id
WHERE s.status IN ('active', 'past_due')
GROUP BY c.name, pl.name, pl.monthly_price, s.status, s.started_at, u.full_name;

De ce mix de INNER și LEFT?

INNER pe customers și plans — un abonament fără client sau fără plan înseamnă date corupte, vrem să cadă raportul vizibil dacă apare.

LEFT pe payments — vrem să listăm abonamentele și fără nicio plată (abonament nou, sau abonament cu probleme).

LEFT pe users — un cont fără account manager e normal pentru clienții mici, nu vrem să-i excludem.

Asta e gândirea practică despre alegerea tipului de JOIN: fiecare JOIN reflectă o decizie de business despre ce se întâmplă când nu există match. Nu e teorie. E semantică.

Caz 4: FULL OUTER JOIN — comparare între sisteme

FULL OUTER JOIN e folosit rar, dar când e potrivit, e singura soluție bună. Cazul tipic: comparare între două surse de date pentru aceeași entitate.

Scenariu: vrei să compari clienții din CRM (HubSpot) cu cei din sistemul de facturare (intern). Întrebări:

Care clienți există în CRM dar nu au facturi (lead-uri necalificate)?
Care au facturi dar nu sunt în CRM (date pierdute)?
Care există în ambele dar au date diferite?

SELECT
  COALESCE(crm.email, inv.email) AS email,
  crm.name AS crm_name,
  inv.company_name AS invoice_company,
  crm.lifecycle_stage AS crm_stage,
  inv.total_invoiced,
  CASE
    WHEN crm.email IS NULL THEN 'doar in facturare'
    WHEN inv.email IS NULL THEN 'doar in CRM'
    ELSE 'in ambele'
  END AS status
FROM crm_customers crm
FULL OUTER JOIN invoice_customers inv ON crm.email = inv.email;

Pentru data reconciliation, FULL OUTER JOIN nu are alternativă elegantă. UNION cu subqueries scrise în 3 părți face același lucru, dar e ilizibil.

MySQL nu suportă FULL OUTER JOIN nativ. Trebuie simulat cu UNION de două LEFT JOIN-uri. PostgreSQL, SQL Server, BigQuery, Snowflake îl suportă direct.

Caz 5: CROSS JOIN — când are sens

CROSS JOIN produce produsul cartezian. 1.000 rânduri × 50 rânduri = 50.000 rânduri. Pare absurd, dar are cazuri legitime.

Cel mai comun: completarea unei serii temporale. Ai vânzări pe zile, dar vrei să raportezi inclusiv zilele cu zero vânzări.

WITH date_series AS (
  SELECT generate_series(
    '2026-12-01'::date,
    '2026-12-31'::date,
    INTERVAL '1 day'
  )::date AS day
),
products_list AS (
  SELECT id, name FROM products WHERE is_active = TRUE
)
SELECT
  ds.day,
  p.name,
  COALESCE(SUM(ol.quantity * ol.unit_price), 0) AS daily_sales
FROM date_series ds
CROSS JOIN products_list p
LEFT JOIN orders o ON o.order_date = ds.day
LEFT JOIN order_lines ol ON ol.order_id = o.id AND ol.product_id = p.id
GROUP BY ds.day, p.name
ORDER BY ds.day, p.name;

CROSS JOIN-ul construiește grila completă „toate zilele × toate produsele”. Apoi LEFT JOIN-urile umplu cu valori reale, restul rămân zero.

Asta e tehnica de bază pentru raportare temporală fără găuri.

SEMI JOIN și ANTI JOIN — pattern-uri uitate

SEMI JOIN — vreau rândurile din tabelul A care AU match în B, dar fără să aduc coloane din B. Se exprimă cu EXISTS:

SELECT *
FROM customers c
WHERE EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.id
    AND o.created_at >= '2026-01-01'
);

Diferența față de INNER JOIN: nu multiplică rândurile dacă în orders sunt mai multe match-uri pentru același client. Plus că e mai ușor de citit semantic.

ANTI JOIN — invers, vreau rândurile din A care NU au match în B:

SELECT *
FROM customers c
WHERE NOT EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.id
);

Alternativ, LEFT JOIN cu IS NULL — vezi caz 2. Diferența: NOT EXISTS e mai performant pe baze mari, optimizatorul o tratează diferit.

Pentru clienți fără comenzi pe baza mare (10M+ clienți), NOT EXISTS rulează în secunde, LEFT JOIN cu IS NULL poate dura minute.

Capcane reale pe care le văd des

Dincolo de teorie, în practică, există patru capcane care apar repetat.

1. Multiplicarea rândurilor. Faci JOIN cu un tabel care are mai multe rânduri per cheie. Suma totală se umflă pentru că rândurile parent sunt duplicate. Soluția: agregare în subquery înainte de JOIN, sau folosire de window functions.

2. NULL în condiții. NULL = NULL e FALSE în SQL. JOIN-urile pe coloane care pot fi NULL nu fac match între NULL-uri. Soluția: COALESCE pe ambele părți cu un sentinel value, sau gestiune explicită.

3. Filtrul în loc greșit. Filtrul în WHERE peste o coloană din tabelul stâng al unui LEFT JOIN — ok. Filtrul în WHERE peste coloana din tabelul drept — transformă LEFT în INNER efectiv. Du-l în ON.

4. JOIN-uri pe tipuri de date diferite. Faci JOIN pe customer_id între două tabele unde într-una e VARCHAR și în alta e INTEGER. Funcționează pe MySQL prin conversie implicită. Pe PostgreSQL aruncă eroare. Pe BigQuery rezultatul depinde de modul de conversie. Verifică mereu tipurile.

Cum testezi că JOIN-urile sunt corecte

Reguli pe care echipele mature le aplică:

Numără rândurile înainte și după JOIN. Dacă numărul a crescut, ai multiplicare. Dacă a scăzut neașteptat, ai pierdut rânduri.
Verifică totaluri agregate. Suma vânzărilor totale după JOIN trebuie să se potrivească cu suma vânzărilor pe tabelul de bază. Dacă nu, ai bug.
Test cu 3-5 cazuri cunoscute. Alege manual câțiva clienți și verifică că query-ul produce ce te aștepți pentru ei.
Testează cu NULL-uri. Forțează intenționat un caz cu NULL pe cheie și verifică comportamentul.

Tema se leagă natural de discuția despre optimizare query, unde am intrat în detaliu pe pattern-urile pe care le observăm în piață. În fond, JOIN SQL nu e doar un concept tehnic — este o decizie de business cu impact direct pe productivitatea echipei.

Recomandarea finală

JOIN-urile SQL nu sunt despre sintaxă. Sunt despre semantică business: ce înseamnă „client”, „comandă”, „vânzare” în contextul tău, și ce vrei să faci când relația dintre ele e parțială.

Trei principii care țin în 95% din cazuri:

Întotdeauna gândește JOIN-ul ca pe o decizie de business, nu ca o operație tehnică.
În rapoartele financiare, LEFT JOIN cu validare explicită. INNER doar conștient.
Numără rândurile. Validează totalurile. Testează cu date cunoscute.

Cea mai mare diferență între un junior și un senior SQL nu e cunoașterea sintaxei. E reflexul de a verifica că rezultatul are sens înainte să-l trimită mai departe.

JOIN-ul greșit nu doare la rulare. Doare în ședința de revizie cu CFO-ul, când întreabă de ce raportul de luna asta diferă de cel din ERP cu 4%.

În practică, JOIN SQL a trecut de la subiect de roadmap la prioritate operațională pentru echipele care livrează rezultate de business — exact tipul de tracțiune pe care o vedem reflectată în deciziile reale de buget. Pentru cititorii care lucrează zilnic cu JOIN SQL, articolul rămâne deschis pentru update-uri pe măsură ce piața evoluează.

Întrebări frecvente

Care e diferența practică între tipurile de JOIN?

INNER JOIN păstrează doar rândurile cu potrivire în ambele tabele. LEFT JOIN păstrează tot din tabelul din stânga, cu NULL unde nu e potrivire. RIGHT JOIN e inversul și e rar folosit, pentru că oamenii îl rescriu ca LEFT. FULL OUTER JOIN păstrează tot din ambele. CROSS JOIN dă produsul cartezian. La ele se adaugă SEMI JOIN și ANTI JOIN, exprimate prin EXISTS și NOT EXISTS.

De ce îmi ies două cifre diferite pentru aceleași vânzări?

Frecvent din cauza JOIN-ului. Un INNER JOIN între comenzi și clienți elimină tăcut comenzile al căror client nu are corespondent — de exemplu clienți șterși sau inactivi — și totalul iese mai mic, fără nicio eroare afișată.

Ce regulă aplică echipele mature?

În query-urile financiare, JOIN-ul implicit ar trebui să fie LEFT, cu validare explicită că nu pierzi rânduri. Iar când vrei să afli ce NU s-a întâmplat — de exemplu produsele fără vânzări în ultimele 90 de zile — întorci logica și cauți rândurile din products care nu au potrivire în order_lines.

🔖Tags: indexes optimizare performance PostgreSQL query rapoarte business SQL