Sollten Fremdschlüssel zum Primärschlüssel der Tabelle werden?

Question

Ich habe eine Tabelle (session_comments) mit der folgenden Feldern Struktur:

student_id (foreign key to students table) 
session_id (foreign key to sessions table) 
session_subject_ID (foreign key to session_subjects table) 
user_id (foreign key to users table) 
comment_date_time 
comment 

nun die Kombination aus STUDENT_ID, session_id und session_subject_id wird eindeutig einen Kommentar zu diesem Schüler identifiziert für diese Sitzung Thema.

Angesichts dieser Kombination sind sie einzigartig, auch wenn sie Fremdschlüssel sind, gibt es einen Vorteil für mich, sie zum kombinierten Primärschlüssel für diesen Tisch zu machen?

Nochmals vielen Dank.

Answer 1

1. Wenn Sie sie zum Primärschlüssel machen, erzwingen Sie die Eindeutigkeit (im Gegensatz zur Implikation).
2. Der Primärschlüssel wird vermutlich gruppiert sein (abhängig von den dbms), was die Leistung für einige Abfragen verbessern wird.
3. Es spart Platz für das Hinzufügen einer eindeutigen Einschränkung, die in einigen DBMS auch einen eindeutigen Index erstellt.

Ob diese drei die Primärschlüssel macht oder nicht, werden Sie noch irgendeine Art von Einzigartigkeit Einschränkung müssen garantieren, dass ein Student kann nicht mit der gleichen Sitzung zugeordnet werden und session_subject_id zweimal. Wenn dieses Szenario zulässig ist, müssen Sie Ihre Eindeutigkeitsbeschränkung um eine weitere Spalte erweitern.

Egal welche Wahl Sie treffen, Sie sollten unbedingt eine Art von Eindeutigkeitseinschränkung auf dem Tisch haben.

Wenn Sie zu diskutieren, ob ein Surrogat Primärschlüssel + eine eindeutige Einschränkung auf die drei Säulen zu schaffen, würde ich sagen, dass es davon abhängt, ob diese Tabelle Kind-Tabellen haben. Wenn dies der Fall ist, ist die Bezugnahme auf den Ersatzschlüssel einfacher und kleiner. Wenn das nicht der Fall ist, dann IMO, gibt Ihnen der Ersatzschlüssel nicht wirklich viel, und Sie könnten genauso gut die drei Spalten als PK verwenden.

Answer 2

Ich würde wirklich empfehlen, dass Sie einen Primärschlüssel verwenden, der von Ihrer Datenbank Ihrer Wahl generiert wird. Vor allem, wenn Sie die Struktur dieser Tabelle während einer zukünftigen Wartung ändern, dann besteht das Risiko, dass Ihr eindeutiger Schlüssel nicht eindeutig wird. Was kann ein wirklich hartes Problem sein, zu sortieren. Auch ein eindeutiger Primärschlüssel macht die Abfrage der Tabelle viel einfacher.

Unique IDs für Postgres: http://www.postgresql.org/docs/8.1/interactive/datatype.html#DATATYPE-SERIAL

Unique IDs für Mysql: http://dev.mysql.com/doc/refman/5.0/en/example-auto-increment.html

Answer 3

Der einzige Grund, warum sie in einen zusammengesetzten Primärschlüssel zu machen wäre ein Kommentar zu erzwingen pro Schüler/Session/Fach. Angenommen, Sie möchten das nicht, würde ich keinen anderen Schlüssel erstellen.

Answer 4

Nein. FREMD-Schlüssel können NULL-Werte enthalten, die in PRIMARY-Schlüsseln nicht zulässig sind. Das Beste, was Sie tun können, ist einen eindeutigen Index aus den Spalten zu erstellen.

Erstellen Sie einen Primärschlüssel auf dem Tisch.

Antwort: Meine nächste Frage ist: Gibt es eine Möglichkeit der Überlappung zwischen den Schlüsseln aus den 4 Tabellen?

Diese beide würde den gleichen Verbund Schlüssel von 101.010.101 erstellen: Schüler: 1010, Sitzung: 10, Betreff: 10, Benutzer: 1 Schüler: 10, Sitzung: 1010, Thema: 10, Benutzer: 1

Ich weise nur darauf hin, dass die vier Spalten eindeutig unterschiedliche Domänen haben sollten, damit die Überlappung die Möglichkeit verringert.

Wahrscheinlich am besten mit einem echten Primärschlüssel zu gehen.

Answer 5

Es hängt vom Rest der Anwendung ab.
Wenn Sie keine Fremdschlüssel für die Kommentartabelle haben (was wahrscheinlich erscheint), ist das in Ordnung.
Wenn Sie auf Kommentare aus einer anderen Tabelle verweisen müssen, wäre es besser, einen eindeutigen Index mit Ihren 3 Feldern plus einem AutoNummer Primärschlüssel zu erstellen, der in anderen Tabellen als Fremdschlüssel dienen wird (viel einfacher und billiger als die 3 Felder).

Answer 6

Die Debatte über natürliche vs künstliche Schlüssel ist so alt wie jede Datenbankimplementierung. Lesen Sie über Pro's und Con's auf wikipedia.

Argumente für die Ersatzschlüssel sind auf theoretischer Ebene leicht zu bestreiten (zum Beispiel Argument, dass mit natürlichen Schlüsseln Sie das Risiko von Ihrem PK werden nicht eindeutig kann mit Antwort - gut argumentiert werden - wenn ich in dieser Situation Es ist gut, dass Dinge brechen würden, anstatt künstlich eindeutige Primärschlüssel mit doppelten Datensätzen für die eigentlichen Daten zu haben.

Ein weiteres gutes Argument ist, dass künstliche Schlüssel entweder redundant sind (es gibt einen anderen eindeutigen Schlüssel in der Tabelle) oder sie erlauben Ihnen, im Wesentlichen nicht eindeutige Datensätze zu speichern.

Noch ist es manchmal so schwierig, gute natürliche Schlüssel zu finden, dass Sie etwas Künstliches wählen müssen und eine Situation zulassen, in der Sie eine Person gleichen Namens, am gleichen Datum (oder mit unbekanntem Datum) mit einer anderen xy-Eigenschaft haben das sind gleiche Werte.

Auch ist es nicht so klar, was künstlich und was natürlich ist. Sie könnten zum Beispiel sagen, dass SSN für Ihre Daten natürlich ist. Auch wenn es sich wirklich um eine Nummer handelt.

Für die Leistung von Multi-Key-Beziehungen - diese sind nicht so schlecht, wie Sie denken, außerdem - segmentiert die Indizes auf natürliche Weise und mit solchen Schlüsseln Sie in der Regel mit einer Datenbank, die wirklich gut mit häufige Abfragen ohne zusätzliche Indizes.

Wenn Sie diese Probleme ernsthaft in Erwägung ziehen, und wenn Sie komplexe System versuchen zu bauen, finden Sie einige gute Literatur (C.J.Date Einführung in Datenbanksysteme, die derzeit in der 8. Auflage in den Sinn kommt)