Natural Keys in Fremdschlüsseln vermeiden

1. Was einen Natural Key als Fremdschlüssel-Ziel auf den ersten Blick attraktiv macht

Ein Natural Key ist ein Wert mit eigenständiger fachlicher Bedeutung, der bereits aus Gründen der Anwendungslogik eindeutig sein muss, etwa eine E-Mail-Adresse bei Benutzerkonten, eine Artikelnummer im Produktkatalog oder eine ISBN bei Büchern. Weil dieser Wert ohnehin als eindeutig gepflegt wird, liegt der Gedanke nahe, ihn direkt als Primärschlüssel zu verwenden und andere Tabellen unmittelbar über diesen fachlichen Wert referenzieren zu lassen, statt eine zusätzliche, rein technische ID-Spalte einzuführen.

Auf den ersten Blick spart das eine Spalte und macht Fremdschlüssel-Werte in Abfrageergebnissen und Debugging-Sitzungen unmittelbar lesbar, ohne einen zusätzlichen Join zur Auflösung zu benötigen. Dieser scheinbare Vorteil hält aber nur so lange an, wie sich der fachliche Wert selbst niemals ändert, eine Annahme, die in der Praxis regelmäßig nicht zutrifft.

2. Das Kernproblem: fachliche Werte ändern sich, technische Identität sollte es nicht

Eine E-Mail-Adresse ändert sich bei Heirat, Domainwechsel oder einfach auf Kundenwunsch. Eine Artikelnummer wird bei einer Umstellung des Nummernsystems, einer Firmenfusion mit überschneidenden Nummernkreisen oder einer Sortimentsbereinigung neu vergeben. Eine ISBN kann sich bei einer Neuauflage desselben inhaltlichen Werks ändern. In all diesen Fällen bleibt die referenzierte Entität dieselbe, nur ihr fachlicher Identifikator wechselt.

Ist dieser fachliche Identifikator gleichzeitig der Primärschlüssel, den andere Tabellen als Fremdschlüssel referenzieren, zwingt jede solche Änderung dazu, den Wert an jeder referenzierenden Stelle im Schema konsistent mitzuändern. Was fachlich eine einzelne, lokale Änderung ist, wird technisch zu einer Kaskade von Updates über potenziell viele Tabellen hinweg.

3. Wie ein Surrogate Key die technische Identität von fachlichen Werten entkoppelt

Ein Surrogate Key ist ein rein technischer, bedeutungsloser Identifikator, typischerweise ein Auto-Increment-Integer oder ein UUID, der ausschließlich der eindeutigen Identifikation einer Zeile dient und niemals fachlich interpretiert wird. Die referenzierten Tabellen zeigen auf diesen stabilen, technischen Wert, während der fachliche Wert, etwa die E-Mail-Adresse, als gewöhnliches, änderbares Attribut in derselben Zeile gepflegt wird, zusätzlich mit einem eigenen Unique Constraint gegen Duplikate abgesichert.

Ändert sich der fachliche Wert, betrifft das ausschließlich ein einzelnes UPDATE auf genau dieser einen Attribut-Spalte in genau dieser einen Zeile. Kein Fremdschlüssel in irgendeiner anderen Tabelle muss angefasst werden, weil kein Fremdschlüssel jemals den fachlichen Wert referenziert hat, sondern immer den stabilen, unveränderten Surrogate Key.

-- Surrogate Key als stabiler Referenzpunkt,
-- E-Mail als gewöhnliches, änderbares Attribut
CREATE TABLE benutzer (
    id    BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    email TEXT NOT NULL UNIQUE
);

CREATE TABLE bestellung (
    id         BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    benutzer_id BIGINT NOT NULL REFERENCES benutzer(id)
);

-- E-Mail-Änderung berührt keinen einzigen Fremdschlüssel
UPDATE benutzer SET email = 'neue-adresse@example.com' WHERE id = 42;

4. Praxisbeispiel: eine schmerzhafte Migration wegen geänderter Artikelnummern

Ein Produktkatalog verwendet zunächst die Artikelnummer direkt als Primärschlüssel, und ein Dutzend weiterer Tabellen, darunter Bestellpositionen, Lagerbestände, Preishistorien und externe Schnittstellen-Mappings, referenzieren diese Artikelnummer als Fremdschlüssel. Nach einer Sortimentsbereinigung sollen mehrere hundert Artikel neue, konsistentere Nummern erhalten, unter anderem weil sich alte und neue Nummernkreise nach einer Übernahme eines anderen Herstellers überschneiden.

Weil die Artikelnummer gleichzeitig Primärschlüssel ist, kann sie nicht einfach per UPDATE geändert werden, ohne vorher jede referenzierende Fremdschlüssel-Beziehung in exakt derselben Transaktion mitzuändern, in vielen Datenbanksystemen zusätzlich unter vorübergehendem Deaktivieren oder als DEFERRED markierten Foreign-Key-Constraints. Bei Tabellen mit Millionen Zeilen und mehreren beteiligten referenzierenden Tabellen wird aus einer eigentlich einfachen fachlichen Umnummerierung ein mehrstündiges, hochriskantes Migrationsprojekt mit Sperrzeiten auf breiter Front.

5. Dieselbe Umnummerierung mit einem Surrogate Key als Primärschlüssel

Wäre stattdessen von Anfang an ein Surrogate Key als Primärschlüssel verwendet worden und die Artikelnummer nur als reguläres, mit Unique Constraint abgesichertes Attribut geführt worden, hätte dieselbe Umnummerierung von mehreren hundert Artikeln aus einer Reihe einfacher UPDATE-Anweisungen auf die Artikelnummer-Spalte bestanden, ohne dass eine einzige Fremdschlüssel-Beziehung in irgendeiner der referenzierenden Tabellen berührt worden wäre.

Der Unterschied zwischen einer riskanten, mehrstündigen Migration mit Sperrzeiten und einer unauffälligen, während des laufenden Betriebs ausführbaren Änderung liegt ausschließlich in dieser einen Schema-Entscheidung, getroffen lange bevor die konkrete Umnummerierung überhaupt absehbar war.

-- Mit Surrogate Key: Umnummerierung ist eine einfache,
-- risikoarme Aktualisierung eines regulären Attributs
UPDATE artikel SET artikelnummer = 'NEU-4471'
    WHERE id = 981234;
-- Keine einzige Fremdschlüssel-Beziehung ist betroffen,
-- weil alle referenzierenden Tabellen auf artikel.id zeigen

6. Weitere Risiken von Natural Keys jenseits der reinen Änderbarkeit

Neben der Änderbarkeit selbst bergen Natural Keys als Primärschlüssel weitere strukturelle Risiken. Text-basierte Natural Keys wie E-Mail-Adressen oder Artikelnummern sind fast immer breiter als ein kompakter Integer, was jeden Fremdschlüssel und jeden Sekundärindex, der diesen Schlüssel referenziert, unnötig vergrößert. Case-Sensitivity-Fragen, führende oder nachgestellte Leerzeichen und unterschiedliche Normalisierungsregeln zwischen Anwendungsschichten können zudem zu subtilen Duplikaten führen, die bei einem rein technischen Surrogate Key gar nicht erst entstehen können.

Hinzu kommt, dass manche vermeintlich stabilen Natural Keys sich bei genauerem Hinsehen als weniger eindeutig erweisen als angenommen. Eine ISBN etwa kann für dieselbe inhaltliche Ausgabe eines Buchs in unterschiedlichen Regionen oder Formaten variieren, was die Annahme einer eins-zu-eins-Beziehung zwischen fachlichem Schlüssel und Entität von Anfang an unterminiert.

7. Wann Natural Keys als Primärschlüssel dennoch vertretbar sind

Nicht jeder Natural Key ist per se problematisch. Bei sehr kleinen, praktisch statischen Referenztabellen, deren Werte fachlich per Definition stabil sind, etwa ISO-Ländercodes oder Währungscodes nach ISO 4217, überwiegt der Vorteil der direkten Lesbarkeit den theoretischen Änderungsaufwand, weil eine Änderung dieser Codes in der Praxis quasi nie vorkommt und selbst dann kontrolliert über eine überschaubare Anzahl an Referenzstellen erfolgen könnte.

Der entscheidende Unterschied zu Anwendungsdaten wie E-Mail-Adressen oder Artikelnummern ist, dass diese Referenzwerte nicht durch Endanwender oder Geschäftsprozesse verändert werden, sondern durch externe, extrem selten aktualisierte Standards definiert sind. Für praktisch alle anderen Fälle mit vom Fachbereich oder von Kunden kontrollierten Werten bleibt ein Surrogate Key die robustere Grundentscheidung.

8. Der fachliche Wert bleibt trotzdem wichtig, nur eben nicht als Primärschlüssel

Der Verzicht auf einen Natural Key als Primärschlüssel bedeutet nicht, auf die fachliche Eindeutigkeitsprüfung zu verzichten. Ein Unique Constraint auf der fachlichen Spalte stellt weiterhin sicher, dass keine zwei Benutzer dieselbe E-Mail-Adresse oder keine zwei Artikel dieselbe Artikelnummer erhalten, ganz unabhängig davon, ob dieser Wert Primärschlüssel ist oder nicht.

Anwendungscode, der einen Benutzer über seine E-Mail-Adresse suchen muss, etwa beim Login, verwendet weiterhin ganz normal eine indizierte Abfrage über diese Spalte. Der Unterschied liegt ausschließlich darin, dass keine andere Tabelle diesen fachlichen Wert als Fremdschlüssel-Ziel referenziert, sondern konsequent den stabilen Surrogate Key.

-- Fachliche Eindeutigkeit bleibt erzwungen,
-- ohne dass die E-Mail Primärschlüssel sein muss
CREATE UNIQUE INDEX idx_benutzer_email ON benutzer (email);

SELECT id FROM benutzer WHERE email = 'kunde@example.com';

9. Praktische Entscheidungsregel für den Schema-Entwurf

Die zentrale Prüffrage beim Schema-Entwurf lautet nicht, ob ein Wert derzeit eindeutig ist, sondern ob er sich in absehbarer Zeit fachlich ändern könnte und ob diese Änderung von Endanwendern, Geschäftsprozessen oder externen Partnern ausgelöst werden kann. Sobald diese Frage auch nur potenziell mit Ja beantwortet wird, gehört der Wert als reguläres, mit Unique Constraint abgesichertes Attribut ins Schema, referenziert wird ausschließlich über einen stabilen Surrogate Key.

Diese Entscheidung frühzeitig zu treffen kostet beim ersten Entwurf nur eine zusätzliche Integer- oder UUID-Spalte. Sie nachträglich zu korrigieren, wie das Beispiel der Artikelnummer-Migration zeigt, kostet potenziell Tage an riskanter, produktionskritischer Migrationsarbeit. Dieses Ungleichgewicht macht Surrogate Keys für Primärschlüssel in praktisch jedem neuen Schema zur Standardwahl.

10. Zusammenfassung

11. FAQ: Natural Keys als Fremdschlüssel-Falle