Klausur-Tricks
Trick 1 — INNER vs. OUTER: alle JOINs außer INNER sind "OUTER" (LEFT, RIGHT, FULL OUTER). LEFT JOIN = LEFT OUTER JOIN, kann beides geschrieben werden.
Trick 2 — Mengen-Bild merken:
INNER → ∩ (Schnittmenge)
LEFT → L (linke ganze Menge + Schnittmenge)
RIGHT → R (rechte ganze Menge + Schnittmenge)
FULL → ∪ (Vereinigung)
Trick 3 — RIGHT in LEFT umschreiben:
A RIGHT JOIN B ON ...
-- ist gleich
B LEFT JOIN A ON ...
Tabellen-Reihenfolge tauschen, dann LEFT statt RIGHT.
Trick 4 — NULL bei OUTER JOINs: bei LEFT/RIGHT/FULL erscheinen NULL-Werte für nicht-gematchte Zeilen. Mit WHERE x IS NULL kannst du gezielt nach "alle Linken OHNE Right-Match" suchen — sehr nützlich für "fehlende" Daten.
-- Studis OHNE Studiengang finden:
SELECT s.name
FROM studierende s
LEFT JOIN studiengaenge sg ON s.sg_id = sg.id
WHERE sg.id IS NULL;
Trick 5 — Cartesian Product (Cross Join) ist gefährlich:
SELECT * FROM tabelleA, tabelleB -- jede mit jeder!
Wenn du die ON-Klausel vergisst, multiplizieren sich die Zeilen. Bei 1000×1000 = 1 Million Zeilen. Klausur-Falle.
Trick 6 — JOIN ist nicht symmetrisch bei OUTER:
A LEFT JOIN B ≠ B LEFT JOIN A
INNER JOIN ist symmetrisch (Schnittmenge ist gleich), OUTER nicht.
Trick 7 — Performance: JOINs nutzen meist Indexe auf den Verknüpfungs-Spalten. Foreign Keys + indexierte Primary Keys → Standard. Ohne Index: full table scan = langsam.
Trick 8 — Mehrere Bedingungen in ON:
INNER JOIN aufgaben a
ON s.id = a.studi_id AND a.semester = 'WS24'
Erlaubt komplexere Verknüpfungen.
Trick 9 — JOIN-Reihenfolge: bei mehreren JOINs ist die Reihenfolge wichtig für Logik (nicht für Performance — die optimiert die DB selbst).
Trick 10 — WHERE statt ON bei OUTER ändert das Ergebnis:
-- LEFT JOIN behält alle Studis, auch ohne sg
LEFT JOIN sg ON s.sg_id = sg.id WHERE sg.name = 'Informatik'
-- → wird zu INNER JOIN, weil WHERE die NULLs rausfiltert!
-- Korrekt: Bedingung in ON:
LEFT JOIN sg ON s.sg_id = sg.id AND sg.name = 'Informatik'
Klausur-Klassiker zum Verständnis.
Wo brauchst du JOINs?
- JEDE relationale DB-Anwendung: Bestellungen + Kunden, Posts + Autoren, Produkte + Kategorien
- Reporting: Umsätze pro Kunde pro Monat = JOIN über Bestellungen + Kunden
- Data Warehouses: Star-Schema mit Fact + Dimensions (alles JOIN)
- OLAP / BI: viele JOINs für komplexe Analysen
- API-Endpoints:
/api/users/:id/orders macht intern JOIN
Faustregel: relationale DBs sind FÜR JOINs gemacht. Wenn du kein JOIN brauchst → vielleicht ist eine andere Datenstruktur (Document, Key-Value) besser.