Sollte ein Primärschlüssel unveränderlich sein?

Eine aktuelle Frage zum Stackoverflow löste eine Diskussion über die Unveränderlichkeit von Primärschlüsseln aus. Ich hatte gedacht, dass es eine Art Regel ist, dass Primärschlüssel unveränderlich sein sollten. Wenn die Möglichkeit besteht, dass eines Tages ein Primärschlüssel aktualisiert wird, sollten Sie einen Ersatzschlüssel verwenden. Es ist jedoch nicht im SQL-Standard enthalten, und bei einigen RDBMS-Funktionen zur "Kaskadenaktualisierung" kann ein Primärschlüssel geändert werden.

Meine Frage lautet also: Ist es immer noch eine schlechte Praxis, einen Primärschlüssel zu haben, der sich ändern kann? Was sind die Nachteile eines veränderlichen Primärschlüssels?

Sie müssen den Primärschlüssel unveränderlich sein , wenn es zu einem Fremdschlüssel verknüpft ist, oder wenn es als eine Kennung außerhalb der Datenbank (zB in einer URL , die auf einer Seite für das Element) verwendet.

Andererseits benötigen Sie nur dann einen veränderlichen Schlüssel, wenn er Informationen enthält, die sich möglicherweise ändern. Ich verwende immer einen Ersatzschlüssel, wenn der Datensatz keinen einfachen, unveränderlichen Bezeichner hat, der als Schlüssel verwendet werden kann.

Ein Primärschlüssel sollte alle Tupel enthalten, die zur Bestimmung der Eindeutigkeit erforderlich sind. Ob sich die Daten ändern können oder nicht, ist unerheblich. Nur die Einzigartigkeit der Aufzeichnung ist von Bedeutung. Das ist das konzeptionelle Design der Datenbank.

Wenn wir in den Bereich der Implementierung eintreten, ist es am sichersten, einfach einen Ersatzschlüssel zu verwenden.

Ja, meiner Meinung nach sollte ein Primärschlüssel unveränderlich sein.

Auch wenn es offensichtliche Kandidatenschlüssel gibt, verwende ich immer einen Ersatzschlüssel. In den wenigen Fällen, in denen ich das nicht getan habe, habe ich es fast immer bereut. Unabhängig davon, wie unveränderlich der Schlüssel Ihrer Meinung nach ist, können Sie sich nicht vor Fehlern bei der Dateneingabe schützen. Teilen Sie den Benutzern mit, dass sie diese Informationen nicht bearbeiten können, da es sich um einen Primärschlüssel handelt.

Caching-Mechanismen zwischen Datenbank und Benutzer verlieren an Effektivität, wenn sich Primärschlüssel ändern.

Warum nicht? Weil du eine Spalte eliminieren willst?

Nur weil die Anforderungen erfordern, dass drei Spalten eindeutig sind, bedeutet dies nicht, dass es sich um den Primärschlüssel handeln muss. Sie denken vielleicht, dass diese Regel für immer gelten wird (Erinnern Sie sich an diese Besprechung, als der Abteilungsleiter schwor, dass sich das nie ändern würde? Sie wissen, die, die gerade gefeuert wurde.), Aber es wird nicht.

Ich werde nicht für jedes von mir implementierte Kaskadenupdate und einen Bonus bezahlt, wenn ich es selbst codiere.

Der Computer benötigt keine Bedeutung für einen Schlüssel. IMHO, Schlüssel sind für Computer, lassen Sie die Leute den Rest der Daten vermasseln.

Es ist keine schlechte Praxis, einen Schlüssel zu haben, dessen Werte sich ändern können.

Zu den Eigenschaften eines guten Schlüssels gehört die Stabilität. Unveränderlichkeit ist ideal, aber keine Voraussetzung. Die Einführung eines künstlichen Schlüssels aus Gründen der Unveränderlichkeit ist eine schlechte Praxis.

Nehmen Sie das Beispiel der International Standard Book Number (ISBN) . Es ist sehr stabil, aber nicht unveränderlich: Manchmal machen Buchverlage Fehler und - Horror! - Doppelte ISBN-Nummern können auftreten. Bedeutet dies, dass ISBN nicht als Kandidatenschlüssel in einer Computerdatenbank akzeptiert werden sollte? Natürlich nicht. Einer der Vorteile von ISBN ist, dass es eine vertrauenswürdige Quelle gibt, die Probleme für alle Benutzer weltweit löst.

Es gibt andere Eigenschaften eines guten ISBN-Schlüssels, die ein bedeutungsloser, automatisch inkrementierender Integer-Schlüssel fehlt, der zB Vertrautheit (jeder im Buchhandel kennt oder mit ISBN vertraut ist), überprüfbar (die ISBN ist auf allen modernen Büchern abgedruckt) kann mit Bezug auf das DBMS validiert werden (ISBN ist eine feste Breite und enthält eine Prüfsumme) usw.

Alles, was möglicherweise unveränderlich sein kann, sollte sein. Es hilft dabei, die Korrektheit sicherzustellen, und es hilft, wenn Sie Ihre Anwendung multithreadingfähig machen möchten.

Ja, ein Primärschlüssel muss unveränderlich und nicht null und eindeutig sein. Ich habe jedoch noch keine Datenbank gefunden, die die Unveränderlichkeit von Primärschlüsseln erzwingt, sodass Sie wahrscheinlich fortfahren und ihre Werte ändern können, wenn Sie dies wirklich möchten.

Wie einige Kommentare bereits sagten, besteht eine Lösung darin, einen neuen Primärschlüssel zu verwenden

Zum Beispiel (nach dem Beispiel von @onedaywhen), nehmen wir an, dass die Tabelle Books existiert, in der eine Liste von Büchern gespeichert ist, und wir "verwendeten", um die ISBN als Primärschlüssel zu bestimmen. Einige Autoren haben jedoch den Fehler begangen, eine falsche ISBN einzugeben, und darum gebeten, die ISBN zu ändern. Dies beinhaltete die folgenden Aufgaben:

• Erstellen Sie eine neue Registrierung in der Tabelle Bücher
• Verweisen Sie alle Verweise von der alten ISBN auf die neue ISBN. (*)
• Und schließlich löschen Sie die alte Registrierung aus der Tabelle Bücher.

(*) Dies kann trivial sein, um alle Referenzen für ein Datenbankmodell zu finden, bei dem Fremdschlüssel verwendet werden, bei einigen Modellen fehlt dies jedoch.

Table Books
ISBN  is the primary key
NAME is a simple field.
etc.

Wir ändern es als

Table Books
InternalBookId as the primary key
ISBN as a simple field or an indexed field.
NAME is a simple field.
etc.

Wobei die neue InternalBookId sogar ein autonumerischer Wert sein könnte.

Die Nachteile davon:

• Es wird ein neues Feld hinzugefügt, das mehr Speicherplatz / Ressource verwendet.

• Möglicherweise muss das gesamte Modell neu geschrieben werden.

• Das neue Modell könnte weniger selbsterklärend sein.

Der Profi

• Ermöglicht das Mutieren des "Primärschlüssels".
• Das Löschen oder Umgestalten des "Primärschlüssels", beispielsweise das Ändern von Büchern in ISBN-13, ist so einfach, dass die ältere Spalte gelöscht und eine neue erstellt wird

Neue Tabelle:

Table Books
InternalBookId as the primary key
ISBN13 is a new field.
NAME is a simple field.
etc.