Primärschlüssel: künstlicher (Surrogat) vs. natürlicher Schlüssel – was nehme ich wann?

Faustregel, mit der du fast immer richtig liegst: Im Zweifel Surrogatschlüssel (also eine künstliche, technische ID). Der Grund ist Stabilität – ein Primärschlüssel sollte sich nie ändern und immer eindeutig sein.

Natürliche Schlüssel klingen elegant, haben aber Tücken:

• Sie können sich ändern (eine Artikelnummer wird umgestellt, ein Nutzername geändert) – und dann musst du die Änderung durch alle Fremdschlüssel-Tabellen schleppen.
• Sie sind manchmal doch nicht so eindeutig, wie man denkt.
• Zusammengesetzte natürliche Schlüssel machen Joins und Fremdschlüssel unhandlich.

Eine technische ID ist dagegen bedeutungslos, unveränderlich und schmal – ideal als Primär- und Fremdschlüssel.

Dem schließe ich mich an, mit einer wichtigen Ergänzung aus der Praxis: Ein Surrogatschlüssel als Primärschlüssel ersetzt nicht die fachliche Eindeutigkeit. Die bildest du zusätzlich über ein UNIQUE-Constraint auf den natürlichen Schlüssel ab.

Beispiel Student: id (Surrogat, Primärschlüssel) + matrikelnummer mit UNIQUE. So hast du beides: eine stabile ID für die Verknüpfungen und die Garantie, dass keine Matrikelnummer doppelt vergeben wird. Genau das übersehen viele in der Klausur – sie werfen den natürlichen Schlüssel ganz weg, und dann kann die Tabelle plötzlich Dubletten enthalten.