Ich habe eine ziemlich einfache Frage über die Verwendung natürlicher / Ersatzschlüssel in einem gut definierten Kontext, der sich oft manifestiert und den ich illustrieren werde.
Nehmen wir an, Sie entwerfen das DB-Schema für ein Produkt mit SQL Server 2005 als DBMS. Der Einfachheit halber nehmen wir an, dass nur zwei Entitäten beteiligt sind, die auf zwei Tabellen, Master und Slave, abgebildet wurden. Angenommen, dass:
Die Frage ist: Wie würden Sie Keys / Constraints / Referenzen für diese Tabellen entwerfen? Würdest du lieber ( argumentieren deine Wahl ):
Was mich betrifft, würde ich mit Option 2 gehen, hauptsächlich wegen der Annahme 3) und der Leistung, aber ich würde gerne die Meinung anderer hören (da es eine offene Diskussion über das Thema gibt).
danke
Entweder 1,2 oder 3. Es gibt nicht unbedingt genügend Informationen, um zu bestimmen, ob ein Ersatz notwendig ist oder wie nützlich er sein könnte. Sind einige der zusammengesetzten Schlüsselattribute auch Teil eines Schlüssels oder einer Einschränkung in der Slave-Tabelle? Gibt es einen anderen Schlüssel des Meisters, der als Fremdschlüssel verwendet werden könnte? Die Tatsache, dass sich ein Schlüsselwert ändern kann, sollte nicht der entscheidende Faktor sein, da sich jeder Schlüsselwert ändern muss - Surrogate sind keine Ausnahme.
Es gibt eine ziemlich offene Debatte über die Thema
Leider basiert ein Großteil dieser Debatte auf der irrigen Annahme, dass Sie zwischen einem Ersatz oder einem natürlichen Schlüssel wählen müssen. Wie Ihre Option 2 zu Recht vorschlägt, können Sie beide nach Bedarf verwenden. Das eine ist kein Ersatz für das andere, weil einfache Schlüssel und zusammengesetzte Schlüssel für verschiedene Attribute offensichtlich unterschiedliche Dinge in Ihrem Datenmodell bedeuten und unterschiedliche Einschränkungen für Ihre Daten erzwingen.
Ich würde für Option 2 gehen. Halten Sie es einfach.
Er setzt die Kontrollkästchen (eng, numerisch, unveränderlich, streng monoton steigend) für einen nützlichen Clustered-Index (der Standard für PKs in SQL Server ist).
Sie müssen die Eindeutigkeit in A,B,C,D jedoch erzwingen, um die Datenintegrität zu erhalten, wie bereits erwähnt.
Mit Option 1 ist konzeptionell nichts falsch, aber sobald Sie mehr Indizes für "Master" benötigen, wird der breite Clusterschlüssel zu einer Verbindlichkeit. Oder mehr Arbeit, um festzustellen, welcher Index als Cluster am besten ist.
Bearbeiten:
Im Falle von Verwirrung
Die Auswahl, welcher Index gruppiert ist, ist getrennt von der Wahl des Schlüssels
Ihre Annahme (3) neigt dazu, Option (2) vorzuschlagen, weil es unpraktisch und möglicherweise zeitaufwendig ist, mit kaskadierenden Aktualisierungen des Primärschlüssels des Masters umzugehen, wenn sich B ändert.
Natürlich hängt es davon ab, wie oft dies geschieht: wenn es etwas ist, von dem Sie erwarten, dass es "die ganze Zeit" passiert, dann ist es (A, B, C, D) eine schlechte Wahl des Primärschlüssels; Auf der anderen Seite, wenn es nur selten passiert, dann (A, B, C, D) kann eine gute Wahl der Primärschlüssel sein, und diese Spalten in Slave haben einige Vorteile (keine Notwendigkeit, mit dem Master alle zu verbinden Zeit, um diese Spaltenwerte herauszufinden).Drei.
Der erste Vorschlag könnte sein, kompostierte Schlüssel zu löschen und ein neues Feld für einen automatischen Schlüssel hinzuzufügen, das nicht mit den anderen Feldern zusammenhängt. Sowohl für die Master- als auch für die Detailtabelle.
Es könnte ein ganzzahliger Autoinkrement-Schlüssel oder ein Global Unique Identifier sein. Zusammengesetzte Schlüssel in jedem S.Q.L. Servermarke, ist schwierig und manchmal sehr schwierig.
Wenn Sie jedoch den zusammengesetzten Schlüssel in der Master-Tabelle behalten möchten, können Sie sich immer noch fragen, wie Sie mit dem Primärschlüssel der Slave-Tabelle umgehen. Viele Entwickler nehmen normalerweise die gleichen Felder für den Primärschlüssel aus der Haupttabelle, fügen sie in die Slave / Detail-Tabelle ein und fügen einen zusätzlichen fortlaufenden Integer-Schlüssel hinzu. Wenn Sie jedoch den Schlüssel für die Master-Tabelle ändern und die bereits vorhandenen Detailzeilen beibehalten möchten, stoßen Sie auf Probleme mit den Einschränkungen der referenziellen Integrität.
Zusammenfassung: Ich schlage vor, f \ u00fcr die Slave-Tabelle ein neues Feld einzuf \ u00fcgen, das nicht mit der Master-Tabelle verwandt ist, f \ u00fcr die Slave- / Detailtabelle einen Fremdschlüssel f \ u00fcr Felder hinzuf \ u00fcgt, der auf die Master-Tabelle verweist. Behalte den Detailprimärschlüssel und den Fremdschlüssel für die Master-Tabelle unabhängig.
Tags und Links sql-server database sql-server-2005 database-design