Gründe, die gegen die Verwendung einer automatisch inkrementierenden Zahl für einen Primärschlüssel sprechen

Question

Ich arbeite derzeit an der Datenbank eines anderen Unternehmens, in der die Primärschlüssel über eine Nachschlagetabelle generiert werden, die eine Liste von Tabellennamen und den zuletzt verwendeten Primärschlüssel enthält. Eine gespeicherte Prozedur erhöht diesen Wert und prüft, ob er eindeutig ist, bevor sie ihn an die aufrufende "insert"-SP zurückgibt.

Welche Vorteile hat die Verwendung einer solchen Methode (oder das Generieren einer GUID) anstelle der Verwendung der Identitäts-/Autonummer?

Ich spreche nicht von Primärschlüsseln, die tatsächlich etwas "bedeuten", wie ISBNs oder Produktcodes, sondern nur von den eindeutigen Bezeichnern.

Danke.

Answer 1

Für die meisten Szenarien, in denen die derzeitige Methode sinnvoll ist, würde ich eine GUID vorziehen (Replikation ist ein mögliches Szenario). Wenn es um Replikation ginge, müsste eine solche gespeicherte Prozedur den anderen Server kennen, der verknüpft werden müsste, um die Eindeutigkeit des Schlüssels zu gewährleisten, was sie sehr spröde und wahrscheinlich eine schlechte Methode wäre.
Eine Situation, in der ich Integer-Primärschlüssel verwende, die NICHT automatisch inkrementierende Identitäten sind, ist der Fall von selten geänderten Nachschlagetabellen, die Fremdschlüsselbeschränkungen erzwingen, die eine entsprechende Aufzählung in der datenverarbeitenden Anwendung haben werden. In diesem Szenario möchte ich sicherstellen, dass die Enum-Zuordnung zwischen Entwicklung und Bereitstellung korrekt ist, vor allem, wenn es mehrere Produktivserver gibt.

Answer 2

Ein weiterer möglicher Grund ist, dass Sie absichtlich zufällige Schlüssel wünschen. Dies kann wünschenswert sein, wenn Sie z. B. nicht wollen, dass neugierige Browser jedes Element in Ihrer Datenbank durchblättern, aber es ist nicht kritisch genug, um tatsächliche Sicherheitsmaßnahmen zur Authentifizierung zu rechtfertigen.

Answer 3

Mein Hauptproblem mit automatisch inkrementierenden Schlüsseln ist, dass sie keine Bedeutung haben.

Für Tabellen, bei denen bestimmte Felder Eindeutigkeit bieten (sei es allein oder in Kombination mit einem anderen), würde ich mich stattdessen dafür entscheiden.

Answer 4

Ein nützlicher Nebeneffekt der Verwendung eines GUID-Primärschlüssels anstelle eines automatisch inkrementierenden Schlüssels besteht darin, dass Sie den PK-Wert für eine neue Zeile auf der Client-Seite zuweisen können (in einem Replikationsszenario müssen Sie dies sogar tun), wodurch Sie sich die Mühe ersparen, den PK-Wert der Zeile, die Sie gerade hinzugefügt haben, auf dem Server abzurufen.

Einer der Nachteile einer GUID-PK ist, dass Joins über ein GUID-Feld langsamer sind (es sei denn, dies hat sich kürzlich geändert). Ein weiterer Vorteil der Verwendung von GUIDs ist, dass es Spaß macht, einem nicht-technischen Manager zu erklären, warum eine GUID-Kollision eher unwahrscheinlich ist.

Answer 5

Die Antwort von Galwegian ist nicht unbedingt richtig.

Bei MySQL können Sie für jede Datenbankinstanz einen Schlüssel-Offset festlegen. Wenn Sie dies mit einem ausreichend großen Inkrement kombinieren, ist das in Ordnung. Ich bin sicher, andere Anbieter haben ähnliche Einstellungen.

Nehmen wir an, wir haben 2 Datenbanken, die wir replizieren wollen. Wir können dies auf folgende Weise einrichten.

increment = 2
db1 - offset = 1
db2 - offset = 2

Dies bedeutet, dass

db1 hat die Tasten 1, 3, 5, 7....

db2 hat die Schlüssel 2, 4, 6, 8....

Daher werden wir keine Schlüsselüberschneidungen bei den Beilagen haben.