INNER und OUTER Join

Beispiel-Schema

Für die folgenden Beispiele nutzen wir zwei Tabellen:

CREATE TABLE customers (
    id   bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name text NOT NULL
);

CREATE TABLE orders (
    id          bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id bigint REFERENCES customers(id),
    total       numeric(10, 2) NOT NULL,
    created_at  timestamptz NOT NULL DEFAULT now()
);

INSERT INTO customers (name) VALUES
    ('Alice'),  -- id 1
    ('Bob'),    -- id 2
    ('Carol');  -- id 3 — bestellt nichts

INSERT INTO orders (customer_id, total) VALUES
    (1, 99.95),    -- Alice
    (1, 49.95),    -- Alice
    (2, 19.95),    -- Bob
    (NULL, 9.95);  -- Bestellung ohne zugewiesenen Kunden

Wichtig für die Beispiele: Carol hat keine Bestellung, und es gibt eine Bestellung ohne Kunden (customer_id IS NULL). Diese Asymmetrie macht den Unterschied zwischen den Join-Typen sichtbar.

INNER JOIN — nur die Schnittmenge

Liefert nur Zeilen, für die in beiden Tabellen ein passender Datensatz existiert:

SELECT c.name, o.total
FROM customers c
INNER JOIN orders o ON o.customer_id = c.id;

Output:

 name  | total
-------+-------
 Alice | 99.95
 Alice | 49.95
 Bob   | 19.95

Carol fehlt (keine Bestellung), und die Bestellung ohne customer_id fehlt (kein passender Kunde). Nur das, was auf beiden Seiten matcht.

INNER ist optional — JOIN allein bedeutet INNER JOIN. Aus Lesbarkeit und Klarheit empfiehlt sich aber, das Wort zu schreiben, gerade in größeren Queries mit gemischten Join-Typen.

LEFT OUTER JOIN — alle Zeilen der linken Tabelle

Liefert alle Zeilen aus der linken Tabelle (customers), plus die passenden aus der rechten (orders). Wo es keinen Treffer gibt, sind die Spalten der rechten Tabelle NULL:

SELECT c.name, o.total
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id;

Output:

 name  | total
-------+-------
 Alice | 99.95
 Alice | 49.95
 Bob   | 19.95
 Carol |  NULL

Carol ist jetzt drin — mit total = NULL, weil sie keine Bestellung hat. Die Bestellung ohne Kunden fehlt weiterhin (sie ist auf der rechten Seite ohne Match).

LEFT JOIN ist die Kurzform von LEFT OUTER JOIN — Postgres akzeptiert beides.

Wann nutzen? Wenn die linke Tabelle das „Hauptobjekt" ist (alle Kunden, auch ohne Bestellung). Klassische Anwendung: „Liste aller User, mit ihrer letzten Bestellung — falls vorhanden".

RIGHT OUTER JOIN — alle Zeilen der rechten Tabelle

Spiegelbild zu LEFT JOIN: alle Zeilen rechts, plus passende von links:

SELECT c.name, o.total
FROM customers c
RIGHT JOIN orders o ON o.customer_id = c.id;

Output:

 name  | total
-------+-------
 Alice | 99.95
 Alice | 49.95
 Bob   | 19.95
 NULL  |  9.95

Jetzt ist die kunden-lose Bestellung dabei (name = NULL), aber Carol fehlt.

In der Praxis sieht man RIGHT JOIN selten — die meisten Leute formulieren denselben Query als LEFT JOIN mit getauschten Tabellen. Lesbarkeit-mäßig die übliche Wahl.

FULL OUTER JOIN — alles aus beiden

Vereinigt LEFT und RIGHT: alle Zeilen aus beiden Tabellen, NULL wo kein Match:

SELECT c.name, o.total
FROM customers c
FULL OUTER JOIN orders o ON o.customer_id = c.id;

Output:

 name  | total
-------+-------
 Alice | 99.95
 Alice | 49.95
 Bob   | 19.95
 Carol |  NULL    -- Carol ohne Bestellung
 NULL  |  9.95    -- Bestellung ohne Kunde

Sehr nützlich für Datenqualitäts-Reports: „zeige mir alles, wo die Verknüpfung nicht sauber ist". Auch hier: OUTER ist optional, FULL JOIN reicht.

Visualisierung mit Venn-Diagrammen

Stell dir die zwei Tabellen als überlappende Kreise vor:

Die NULL-Werte entstehen genau dort, wo eine Seite ohne Match ist.

USING — kürzer, wenn die Spalten gleich heißen

Wenn die Join-Spalten in beiden Tabellen denselben Namen haben, kann man sich die ON ... = ...-Schreibweise sparen:

SELECT *
FROM order_items oi
INNER JOIN products p ON p.id = oi.product_id;

SELECT *
FROM order_items oi
INNER JOIN products p USING (product_id);

Voraussetzung: beide Tabellen müssen eine Spalte product_id haben. Bei USING taucht die Spalte im Resultset nur einmal auf (statt einmal aus jeder Seite).

In gut benannten Schemas kommt das oft nicht vor — typische Konvention ist id in der einen Tabelle, <entity>_id in der anderen. Daher meist ON.

Mehrere Joins kombinieren

In realen Queries werden mehrere Tabellen zusammengeführt:

SELECT
    c.name             AS customer,
    o.id               AS order_id,
    o.total,
    p.name             AS product,
    oi.quantity
FROM customers c
INNER JOIN orders o      ON o.customer_id = c.id
INNER JOIN order_items oi ON oi.order_id = o.id
INNER JOIN products p     ON p.id = oi.product_id
WHERE o.created_at >= now() - interval '30 days'
ORDER BY o.created_at DESC, o.id, p.name;

Postgres liest das von oben nach unten: erst customers mit orders joinen (über customer_id), dann das Ergebnis mit order_items (über order_id), dann mit products (über product_id). Der Optimizer ordnet das intern oft anders an, das Resultat bleibt dasselbe.

Kombinierte Join-Typen

Du kannst INNER und LEFT in einer Query mischen:

SELECT
    c.name,
    o.total,
    a.city
FROM customers c
INNER JOIN orders o    ON o.customer_id = c.id    -- nur Kunden mit Bestellung
LEFT  JOIN addresses a ON a.customer_id = c.id;   -- Adresse optional

Hier sind nur Kunden im Resultat, die mindestens eine Bestellung haben (INNER), aber sie kommen auch ohne Adresse durch (LEFT). Eine flexible Kombination — solange du nachvollziehst, welche Seite welcher Join-Bedingung dominiert.

Mehrfach-Treffer und Zeilen-Multiplikation

Wenn die rechte Seite mehrere passende Zeilen pro linke hat, multipliziert sich das Resultat. Das ist oft beabsichtigt, kann aber überraschen:

myapp=> SELECT c.name, o.id AS order_id, o.total
        FROM customers c
        INNER JOIN orders o ON o.customer_id = c.id
        WHERE c.name = 'Alice';

 name  | order_id | total
-------+----------+-------
 Alice |        1 | 99.95
 Alice |        2 | 49.95

Alice taucht zweimal auf, weil sie zwei Bestellungen hat. Wenn man pro Kunde eine Zeile will (z. B. mit der Summe der Bestellungen), nutzt man GROUP BY:

SELECT
    c.name,
    count(o.id)     AS order_count,
    sum(o.total)    AS total_revenue
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.name
ORDER BY c.name;

GROUP BY ist dann das richtige Werkzeug — siehe Kapitel Aggregation.

Weiterführende Ressourcen

Externe Quellen

• SELECT – Joined Tables – PostgreSQL Documentation
• SQL Joins – PostgreSQL Tutorial
• SQL Standard – ISO/IEC 9075

Verwandte Artikel

• LEFT, RIGHT, FULL OUTER — Details und Stolperfallen
• CROSS und LATERAL Join
• Self-Join
• EXISTS vs. IN vs. JOIN
• SELECT und WHERE