Composite Keys vs. Surrogate Keys in Verbindungstabellen

1. Die zwei Grundmuster für Verbindungstabellen im Überblick

Eine klassische Many-to-Many-Beziehung, etwa zwischen Benutzern und Rollen oder zwischen Artikeln und Kategorien, wird relational über eine eigene Verbindungstabelle mit zwei Fremdschlüsseln abgebildet. Für den Primärschlüssel dieser Tabelle gibt es zwei etablierte Muster: den Composite Key, bei dem beide Fremdschlüssel-Spalten gemeinsam den Primärschlüssel bilden, und den Surrogate Key, bei dem eine zusätzliche, technische ID-Spalte den Primärschlüssel übernimmt, während die beiden Fremdschlüssel über einen separaten Unique Constraint gegen Duplikate abgesichert werden.

Beide Varianten stellen dieselbe fachliche Eindeutigkeitsregel sicher, nämlich dass eine Kombination aus beiden referenzierten Entitäten nur einmal vorkommen darf. Der Unterschied liegt in den strukturellen Konsequenzen für Index, Speicherbedarf, referenzierende Tabellen und die Integration in Anwendungscode.

2. Composite Key: Eindeutigkeit direkt über den Primärschlüssel erzwungen

Bei einem Composite Key aus beiden Fremdschlüsseln ist die Eindeutigkeit strukturell garantiert, ganz ohne separaten Unique Index. Der Primärschlüssel-Index dient gleichzeitig als effizienter Zugriffspfad für Abfragen, die nach beiden Fremdschlüsseln gemeinsam filtern, und in vielen Datenbanksystemen auch als guter Zugriffspfad für Abfragen, die nur nach dem ersten Teil des zusammengesetzten Schlüssels filtern, weil der B-Tree über die erste Spalte sortiert beginnt.

Da keine zusätzliche technische ID-Spalte existiert, entfällt auch der Speicherbedarf für einen zusätzlichen Index. Für eine sehr einfache Verbindungstabelle ohne weitere Attribute, deren einziger Zweck die reine Existenz einer Beziehung ist, ist der Composite Key deshalb häufig die kompaktere und direktere Lösung.

-- Composite Key: beide Fremdschlüssel bilden gemeinsam
-- den Primärschlüssel der Verbindungstabelle
CREATE TABLE benutzer_rolle (
    benutzer_id BIGINT NOT NULL REFERENCES benutzer(id),
    rolle_id    BIGINT NOT NULL REFERENCES rolle(id),
    PRIMARY KEY (benutzer_id, rolle_id)
);

3. Surrogate Key: eine stabile ID für Referenzen von außen

Sobald eine Verbindungstabelle mehr ist als reine Existenzmarkierung, etwa weil sie Zusatzattribute wie einen Zeitstempel, eine Menge oder einen Status trägt, wird eine eigene Surrogate-ID wertvoll. Diese ID bietet einen einzigen, stabilen Referenzpunkt, über den sich einzelne Zeilen der Verbindungstabelle eindeutig ansprechen lassen, unabhängig davon, wie viele Spalten die fachliche Eindeutigkeit definieren.

Das wird besonders relevant, sobald eine weitere Tabelle wiederum auf eine konkrete Zeile der Verbindungstabelle verweisen muss, etwa ein Audit-Log, das protokolliert, wann eine bestimmte Benutzer-Rolle-Zuordnung geändert wurde, oder eine Historie-Tabelle mit Versionsständen. Ein Fremdschlüssel auf einen Composite Key erfordert dann zwei Spalten in der referenzierenden Tabelle, ein Fremdschlüssel auf einen Surrogate Key genügt mit einer einzigen Spalte.

-- Surrogate Key: eigene ID plus Unique Constraint
-- für die fachliche Eindeutigkeit
CREATE TABLE bestellposition (
    id           BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    bestellung_id BIGINT NOT NULL REFERENCES bestellung(id),
    artikel_id   BIGINT NOT NULL REFERENCES artikel(id),
    menge        INT NOT NULL CHECK (menge > 0),
    einzelpreis  NUMERIC(10,2) NOT NULL,
    UNIQUE (bestellung_id, artikel_id)
);

4. Praktisches Beispiel: Verbindungstabelle mit Zusatzattributen

Eine Bestellposition, die eine Bestellung mit einem Artikel verknüpft, ist ein typisches Beispiel für eine Verbindungstabelle mit Zusatzattributen. Menge und Einzelpreis gehören fachlich eindeutig zur einzelnen Zuordnung zwischen Bestellung und Artikel, nicht zu einer der beiden referenzierten Entitäten selbst. Sobald ein Warenkorb- oder Retouren-Prozess einzelne Bestellpositionen adressieren muss, etwa um eine Teilmenge zu stornieren oder eine Retoure gezielt einer Position zuzuordnen, wird eine eigene, stabile ID für jede Zeile praktisch unverzichtbar.

Mit einem reinen Composite Key aus Bestellung und Artikel müsste jede referenzierende Operation immer beide Werte mitführen, was bei mehrstufigen Prozessen wie Teillieferungen oder mehreren Retouren-Vorgängen pro Position schnell unübersichtlich wird. Die Surrogate-ID entkoppelt die technische Referenz von der fachlichen Beziehung und macht jede einzelne Position eindeutig adressierbar.

5. Auswirkung auf ORM-Kompatibilität und Anwendungscode

Viele objektrelationale Mapper sind primär auf einspaltige Surrogate Keys ausgelegt und unterstützen Composite Keys nur mit zusätzlicher Konfiguration oder eingeschränktem Funktionsumfang, etwa bei Lazy-Loading-Strategien, Caching-Schlüsseln oder generischen Repository-Implementierungen, die intern von einer einzelnen ID-Spalte ausgehen. Ein Composite Key erzwingt an diesen Stellen häufig Sonderbehandlung, die den ansonsten einheitlichen Umgang mit Entitäten aufweicht.

Ein Surrogate Key fügt sich dagegen nahtlos in Standard-ORM-Muster ein: jede Zeile hat eine einzelne, eindeutige ID, Beziehungen lassen sich wie bei jeder anderen Entität abbilden, und generische Wiederverwendung von Repository- oder Data-Access-Code funktioniert ohne Sonderfälle. Das reine SQL-Modell profitiert von dieser Entscheidung nicht direkt, wohl aber die Konsistenz und Wartbarkeit des darüberliegenden Anwendungscodes.

6. Auswirkungen auf nachgelagerte Fremdschlüsselbeziehungen

Ein Composite Key als Ziel eines Fremdschlüssels bedeutet, dass jede referenzierende Tabelle beide Spalten redundant mitführen muss, was den Speicherbedarf und die Breite jedes betroffenen Index erhöht. Bei mehreren nachgelagerten Tabellen, die jeweils auf dieselbe Verbindungstabelle verweisen, summiert sich dieser Overhead, und jede referenzierende Abfrage muss konsequent beide Spalten im Join-Prädikat führen.

Ein Surrogate Key hält jede nachgelagerte Fremdschlüssel-Beziehung auf eine einzelne, kompakte Spalte reduziert, unabhängig davon, wie viele Spalten die fachliche Eindeutigkeit der Verbindungstabelle selbst definieren. Das vereinfacht sowohl das Schema als auch jede Abfrage, die über mehrere Ebenen von Beziehungen hinweg joint.

7. Warum der Unique Constraint beim Surrogate Key nicht optional ist

Wer sich für einen Surrogate Key entscheidet, darf den separaten Unique Constraint auf die fachlichen Fremdschlüssel-Spalten nicht vergessen. Ohne diesen Constraint verliert die Tabelle ihre fachliche Integrität vollständig, denn die reine Existenz einer technischen ID verhindert keine doppelten Zuordnungen derselben beiden Entitäten. Dieser Fehler tritt in der Praxis überraschend häufig auf, weil die primäre Aufmerksamkeit beim Schema-Design auf dem Primärschlüssel liegt und der zusätzliche Constraint leicht übersehen wird.

Der Unique Constraint auf den fachlichen Spalten erzeugt in den meisten Datenbanksystemen automatisch einen eigenen Index, der zusätzlich zum Primärschlüssel-Index gepflegt werden muss. Das ist ein bewusster Trade-off: mehr Speicherbedarf und ein zweiter zu pflegender Index gegen eine stabile, einspaltige Referenz für alle nachgelagerten Beziehungen.

-- Ohne diesen Constraint verhindert der Surrogate Key
-- selbst KEINE doppelten Zuordnungen
ALTER TABLE bestellposition
    ADD CONSTRAINT uq_bestellung_artikel UNIQUE (bestellung_id, artikel_id);

8. Performance-Unterschiede bei typischen Abfragemustern

Für Abfragen, die ausschließlich nach beiden Fremdschlüsseln gemeinsam filtern, etwa die Prüfung, ob eine bestimmte Benutzer-Rolle-Kombination existiert, ist der Composite Key in der Regel minimal effizienter, weil kein zusätzlicher Index-Lookup über den Unique Constraint nötig ist. Für Abfragen, die eine einzelne Zeile über ihre eigene ID ansprechen, etwa beim Aktualisieren einer bestimmten Bestellposition, ist der Surrogate Key im Vorteil, weil der Zugriff über einen kompakten, einspaltigen Index erfolgt.

In der Praxis überwiegt bei Tabellen mit Zusatzattributen fast immer der zweite Zugriffsmuster-Typ, weil Anwendungscode einzelne Zeilen typischerweise über ihre technische ID lädt, ändert und referenziert, sobald die Verbindungstabelle mehr als eine reine Existenzaussage trägt. Der geringe Performance-Vorteil des Composite Keys bei reinen Existenzprüfungen wiegt diesen praktischen Nachteil selten auf.

9. Entscheidungshilfe: wann welcher Ansatz die bessere Wahl ist

Ein Composite Key eignet sich für reine Existenz-Verbindungstabellen ohne Zusatzattribute und ohne die Notwendigkeit, dass andere Tabellen auf einzelne Zeilen der Verbindungstabelle verweisen, etwa eine einfache Tag-Zuordnung oder eine reine Berechtigungszuordnung ohne weitere Metadaten. Der Composite Key bleibt hier die kompaktere, direktere Lösung ohne unnötigen zusätzlichen Index.

Sobald Zusatzattribute hinzukommen, eine nachgelagerte Tabelle auf einzelne Zeilen verweisen muss, oder das verwendete ORM Composite Keys nur eingeschränkt unterstützt, ist ein Surrogate Key mit begleitendem Unique Constraint die robustere Wahl. Diese Entscheidung sollte am Anfang des Schema-Designs getroffen werden, denn ein nachträglicher Wechsel von Composite zu Surrogate Key erfordert eine Migration aller bereits bestehenden nachgelagerten Fremdschlüsselbeziehungen.

10. Zusammenfassung

11. FAQ: Composite vs. Surrogate Keys