Da haben wir es wieder, das alte Argument taucht immer noch auf...
Wäre es besser, einen Geschäftsschlüssel als Primärschlüssel zu verwenden, oder sollten wir lieber eine Ersatzkennung (d. h. eine SQL Server-Identität) mit einer eindeutigen Einschränkung für das Geschäftsschlüsselfeld verwenden?
Bitte geben Sie Beispiele oder Beweise an, um Ihre Theorie zu untermauern.
Zur Erinnerung: Es ist keine gute Praxis, geclusterte Indizes auf zufällige Surrogatschlüssel zu platzieren, z. B. GUIDs, die XY8D7-DFD8S lauten, da SQL Server keine Möglichkeit hat, diese Daten physisch zu sortieren. Sie sollten stattdessen eindeutige Indizes auf diese Daten setzen, obwohl es auch von Vorteil sein kann, einfach den SQL Profiler für die Haupttabellenoperationen auszuführen und diese Daten dann in den Database Engine Tuning Advisor zu setzen.
Siehe Thema @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be
Das ist nicht korrekt, denn sie können zwar die GUID auswerten, aber die daraus resultierende Sortierung ist für einen Menschen nicht unsinnig. stackoverflow.com/questions/7810602/
Bei einer zeitpunktbezogenen Datenbank ist es am besten, eine Kombination aus Surrogat- und natürlichen Schlüsseln zu verwenden. z.B. müssen Sie die Mitgliederdaten eines Vereins verfolgen. Einige Attribute eines Mitglieds ändern sich nie, z. B. das Geburtsdatum, aber der Name kann sich ändern. Erstellen Sie also eine Tabelle "Mitglied" mit einem Surrogatschlüssel member_id und einer Spalte für das Geburtsdatum. Erstellen Sie eine weitere Tabelle mit dem Namen person name und Spalten für member_id, member_fname, member_lname, date_updated. In dieser Tabelle wäre der natürliche Schlüssel member_id + date_updated.
Pferd für Kurse. Um meine Voreingenommenheit zu verdeutlichen: Ich bin in erster Linie Entwickler, also geht es mir hauptsächlich darum, den Benutzern eine funktionierende Anwendung zu bieten.
Ich habe an Systemen mit natürlichen Schlüsseln gearbeitet und musste viel Zeit aufwenden, um sicherzustellen, dass sich Wertänderungen durchsetzen.
Ich habe an Systemen gearbeitet, die nur Ersatzschlüssel verwenden, und der einzige Nachteil war der Mangel an denormalisierten Daten für die Partitionierung.
Die meisten traditionellen PL/SQL-Entwickler, mit denen ich zusammengearbeitet habe, mochten Surrogatschlüssel wegen der Anzahl der Tabellen pro Join nicht, aber unsere Test- und Produktionsdatenbanken kamen nie ins Schwitzen; die zusätzlichen Joins beeinträchtigten die Anwendungsleistung nicht. Bei Datenbankdialekten, die Klauseln wie "X inner join Y on X.a = Y.b" nicht unterstützen, oder bei Entwicklern, die diese Syntax nicht verwenden, machen die zusätzlichen Joins für Surrogatschlüssel die Abfragen schwieriger zu lesen und verlängern die Eingabe und Überprüfung: siehe Beitrag von @Tony Andrews. Aber wenn Sie ein ORM oder ein anderes Framework zur SQL-Generierung verwenden, werden Sie das nicht bemerken. Touch-Typing mildert das Problem ebenfalls.
Außerdem: Wenn Sie wirklich deutlich machen wollen, dass die Ersatzschlüssel nur das sind, beginnen Sie mit einer zufälligen großen Zahl und erhöhen Sie die Sequenzen um 3+ statt um 1. Oder verwenden Sie dieselbe Sequenz, um Werte für mehr als einen Schlüssel zu erzeugen.
Vielleicht nicht ganz relevant für dieses Thema, aber ein Problem, das ich im Umgang mit Ersatzschlüsseln habe. Oracle Pre-Delivered Analytics erstellt automatisch generierte SKs für alle Dimensionstabellen im Warehouse und speichert diese auch in den Fakten. Wenn diese (Dimensionen) neu geladen werden müssen, weil neue Spalten hinzugefügt oder alle Elemente in der Dimension aufgefüllt werden müssen, sind die SKs, die während der Aktualisierung zugewiesen werden, nicht mehr mit den ursprünglichen Werten synchron, die im Fakt gespeichert sind. Selbst wenn die SK eine bedeutungslose Zahl wäre, würde ich es vorziehen, wenn es eine Möglichkeit gäbe, dass sie sich für ursprüngliche/alte Datensätze nicht ändern könnte. Wie viele wissen, erfüllen die Standardlösungen nur selten die Anforderungen einer Organisation, und wir müssen sie ständig anpassen. Wir haben jetzt Daten aus 3 Jahren in unserem Warehouse, und die kompletten Neueinspielungen aus den Oracle-Finanzsystemen sind sehr umfangreich. In meinem Fall werden sie also nicht aus der Dateneingabe generiert, sondern in einem Warehouse hinzugefügt, um die Berichtsleistung zu verbessern. Ich verstehe das, aber unsere Daten ändern sich, und das ist ein Albtraum.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
26 Stimmen
@Joachim Sauer: Ein Argument darüber, ob eine Sache subjektiv ist, kann selbst subjektiv sein, ohne dass dies in irgendeiner Weise mit der Objektivität oder Subjektivität der fraglichen Sache zu tun hat. Es sei denn, Sie sind bereit, die genauen objektiven Kriterien zu nennen, die etwas objektiv machen. Es gibt Dinge, die man "offene Begriffe" nennt, wie zum Beispiel die Anzahl der Haare, die ein Bart braucht. Man kann objektiv sagen, dass eine Person ohne Kinnhaare keinen Bart hat, und eine mit 5.000 Haaren pro Zentimeter Länge hat einen Bart, aber irgendwo in der Mitte ist ein subjektives Urteil erforderlich, um eine objektive Feststellung zu treffen.
2 Stimmen
@Manrico: Sie müssen sich nur Folgendes fragen: Wenn ich keinen Ersatzschlüssel verwende, ist mein Primärschlüssel dann immer noch unveränderlich? Wenn die Antwort nein lautet, dann sollten Sie ernsthaft die Verwendung eines Ersatzschlüssels in Betracht ziehen. Auch wenn der Primärschlüssel auch nur teilweise aus Benutzereingaben besteht, sollten Sie die Verwendung eines Ersatzschlüssels in Betracht ziehen. Und warum? Wegen der Gefahr von Datenanomalien.
1 Stimmen
@TylerRick Aber das ist keine wirklich gute Frage. Sie fragt nach einer allgemeingültigen Lösung für alle Situationen, obwohl es offensichtlich keine gibt, wie der "Religionskrieg" beweist, dessen sich der Fragesteller sehr wohl bewusst ist (Zitat: "Da haben wir es wieder, das alte Argument taucht immer noch auf..."). Anstatt sich zu fragen, ob sich die Welt verändert hat und endlich ein zwingender Grund vorliegt, sich immer für eine Seite zu entscheiden, ist es besser, diese Frage für jede konkrete Situation immer wieder zu stellen und SO zu posten, wenn man sich nicht sicher ist. Das ruft nur Dogmatismus hervor.