Surrogat- oder natürlicher Schlüssel: So trifft man die richtige Entscheidung

Der Theorie relationaler Datenbanken zufolge muss eine korrekt normalisierte Tabelle über einen Primärschlüssel verfügen. Allerdings streiten sich Datenbankentwickler darüber, ob Surrogatschlüssel oder natürliche Schlüssel besser sind. Daten enthalten einen natürlichen Schlüssel. Ein Surrogatschlüssel ist ein bedeutungsloser Wert, der gewöhnlich vom System generiert wird. Manche Entwickler verwenden beide Schlüsselarten und entscheiden je nach Anwendung und Daten, während andere sich strikt an eine Schlüsselart halten.

Die folgenden Tipps bevorzugen überwiegend Surrogatschlüssel (wie die Autorin auch), aber es sollte auf keinen Fall eine Versteifung auf eine Schlüsselart stattfinden. Am besten ist es, praktisch, vernünftig und realistisch vorzugehen und den Schlüssel zu verwenden, der einem jeweils am besten geeignet erscheint. Jeder Entwickler sollte aber stets bedenken, dass er sich mit seiner Wahl langfristig festlegt, was im weiteren Verlauf auch andere betrifft.

1. Ein Primärschlüssel muss einzigartig sein

Ein Primärschlüssel identifiziert in eindeutiger Weise jeden Eintrag in einer Tabelle und verknüpft die Einträge mit anderen Daten, die in anderen Tabellen gespeichert sind. Ein natürlicher Schlüssel kann mehrere Felder benötigen, um für jeden Eintrag eine eindeutige Identität zu erzeugen. Ein Surrogatschlüssel ist ohnehin schon einzigartig.

2. Der Primärschlüssel sollte so kompakt wie möglich sein

In diesem Fall bedeutet kompakt, dass zur eindeutigen Identifizierung jedes Eintrags nicht allzu viele Felder erforderlich sein sollten. Um zuverlässige Daten zu erhalten, können mehrere Felder erforderlich sein. Entwickler, die der Ansicht sind, dass natürliche Schlüssel besser seien, verweisen oft darauf, dass die Verwendung eines Primärschlüssels mit mehreren Feldern nicht schwieriger sei als die Arbeit mit einem nur ein Feld umfassenden Primärschlüssel. In der Tat kann es mitunter ganz einfach sein, es kann einen aber auch zur Verzweiflung bringen.

Ein Primärschlüssel sollte kompakt sein und so wenige Felder wie möglich enthalten. Ein natürlicher Schlüssel kann viele Felder erfordern. Ein Surrogatschlüssel erfordert nur ein Feld.

3. Es kann natürliche Schlüssel mit nur einem Feld geben

Manchmal gibt es für Daten einen Primärschlüssel mit nur einem Feld. Unternehmenseigene Codes, Bauteilnummern und ISO-normierte Artikel sind Beispiele hierfür. In diesen Fällen erscheint das Hinzufügen eines Surrogatschlüssels zwar überflüssig, doch sollte man seine endgültige Entscheidung sorgfältig abwägen. Auch wenn die Daten für den Moment stabil erscheinen, kann der Schein trügen. Daten und Regeln ändern sich (siehe Punkt 4).

4. Primärschlüsselwerte sollten stabil sein

Ein Primärschlüssel muss stabil sein. Der Wert eines Primärschlüssels sollte grundsätzlich nicht geändert werden. Leider sind aber Daten nicht stabil. Außerdem unterliegen natürliche Daten Geschäftsregeln und anderen Einflüssen, die sich der Kontrolle des Entwicklers entziehen. Entwickler wissen und akzeptieren das.
Ein Surrogatschlüssel ist ein bedeutungsloser Wert ohne jegliche Beziehung zu den Daten, weshalb keinerlei Grund besteht, ihn jemals zu ändern. Wenn man also gezwungen ist, den Wert eines Surrogatschlüssels zu ändern, bedeutet dies, dass etwas falsch gemacht wurde.

5. Man muss den Wert des Primärschlüssels kennen, um den Eintrag erstellen zu können

Der Wert eines Primärschlüssels kann nie null sein. Das bedeutet, dass man den Wert des Primärschlüssels kennen muss, um einen Eintrag zu erstellen. Sollte ein Eintrag erstellt werden, bevor der Wert des Primärschlüssels bekannt ist? In der Theorie lautet die Antwort hierauf nein. Die Praxis zwingt einen jedoch manchmal dazu.
Das System erstellt Werte für Surrogatschlüssel, wenn ein neuer Eintrag erstellt wird, so dass der Wert des Primärschlüssels existiert, sobald der Eintrag existiert.

6. Es sind keine doppelten Einträge zulässig

Eine normalisierte Tabelle kann keine doppelten Einträge enthalten. Aus mechanischer Sicht ist dies zwar möglich, doch widerspricht es der relationalen Theorie. Ein Primärschlüssel kann auch keine doppelten Werte enthalten, wobei ein eindeutiger Index doppelte Werte verhindert. Diese beiden Regeln ergänzen sich und werden häufig als Argument für natürliche Schlüssel angeführt. Die Verfechter natürlicher Schlüssel verweisen darauf, dass ein Surrogatschlüssel doppelte Einträge zulässt. Wenn man einen Surrogat-Primärschlüssel verwenden möchte, genügt es, einen Index für die entsprechenden Felder anzuwenden, und ist das Problem gelöst.

7. Benutzer möchten den Primärschlüssel sehen

Es herrscht ein Missverständnis über den Bedarf des Benutzers, den Wert des Primärschlüssels zu kennen. Es gibt keinen Grund, weder theoretischer noch anderer Natur, weshalb Benutzer den Primärschlüsselwert eines Eintrags sehen sollten. Tatsächlich müssen die Benutzer noch nicht einmal wissen, dass ein solcher Wert existiert. Er ist im Hintergrund aktiv und hat keinerlei Bedeutung für den Benutzer, wenn er diese Daten eingibt und aktualisiert, Berichte ausführt usw. Es besteht keine Notwendigkeit, den Primärschlüsselwert dem Eintrag selbst zuzuordnen. Wer sich erst einmal von der Vorstellung verabschiedet hat, dass die Benutzer den Primärschlüsselwert brauchen, steht der Nutzung eines Surrogatschlüssels offener gegenüber.

8. Surrogatschlüssel fügen ein unnötiges Feld hinzu

Die Verwendung eines Surrogatschlüssels erfordert ein Zusatzfeld, was manche als Platzverschwendung betrachten. Letztlich ist alles, was für die eindeutige Identifizierung des Eintrags und seine Verknüpfung mit Daten in anderen Tabellen erforderlich ist, bereits im Eintrag vorhanden. Warum also eine zusätzliche Spalte mit Daten hinzufügen, um das zu erreichen, was die Daten auch allein können?
Der Aufwand für ein selbstgenerierendes Wertfeld ist minimal und erfordert keine Wartung. Für sich allein genommen, ist dies noch kein ausreichender Grund für die Empfehlung eines natürlichen Schlüssels, aber es ist ein gutes Argument.

9. Machen Systeme nicht Fehler?

Nicht jeder vertraut systemgenerierten Werten. Systeme können Fehler machen. Das kommt zwar im Grunde nie vor, ist aber theoretisch möglich. Auf der anderen Seite kann ein für diese Art von Störungen anfälliges System auch Probleme mit einem natürlichen Wert bekommen. Um es ganz klar zu sagen: Die beste Möglichkeit, um eine komplette Datenbank, und nicht nur die Primärschlüsselwerte, zu schützen, besteht darin, regelmäßige Backups von ihr zu erstellen. Natürliche Daten sind auch nicht zuverlässiger als ein systemgenerierter Wert.

10. Manche Umstände scheinen einen natürlichen Schlüssel zu erfordern

Der einzige Grund, weshalb unbedingt ein natürlicher Schlüssel erforderlich sein könnte, sind Einträge in integrierten Systemen. Mit anderen Worten: Manchmal erstellen Anwendungen, die ähnliche Tabellen gemeinsam nutzen, unabhängig voneinander neue Einträge. Wenn man keine Vorkehrungen trifft, werden die beiden Datenbanken vermutlich dieselben Werte generieren. Ein natürlicher Schlüssel würde in diesem Fall jegliche doppelten Primärschlüsselwerte verhindern.
Es gibt einfache Tricks, um hier einen Surrogatschlüssel einzusetzen. Jedem System lässt sich ein anderer Startwert geben, aber selbst das kann Probleme verursachen. GUIDs funktionieren zwar, beeinträchtigen aber häufig die Performance. Eine weitere Alternative wäre ein kombiniertes Feld aus dem systemgenerierten Feld des Eintrags und einem Quellcode, das nur bei einer Verbindung der Datenbanken zum Einsatz kommt. Es gibt noch weitere Möglichkeiten, wenngleich ein natürlicher Schlüssel in dieser Situation die vernünftigste Option zu sein scheint.