Kann eine Verbindung Schlüssel als Primärschlüssel an einem anderen Tisch gesetzt werden?

Question

Kann eine Verbindung Schlüssel als Primärschlüssel an einem anderen Tisch gesetzt werden?

Zum Beispiel habe ich die Tabellen:

• Books -mit Primary Key: Product_ID
• Client -mit Primärschlüssel: Client_ID
• Clients_Books -mit Verbindung Primärschlüssel: Product_Id und Client_ID

Ich möchte von Clients_Books als Primärschlüssel dieser Verbindung Primärschlüssel setzen auf eine andere Tabelle mit dem Namen: Order_Details. Aber ich will nicht die Product_ID verwenden und die CLIENT_ID aus den Büchern, Clients Tabellen.

Ist das sinnvoll? Alle Meinungen mehr als willkommen.

Answer 1

Die kurze Antwort ist, Nein - das geht nicht. Alle Spalten in der PK (oder einem anderen alternativen Schlüssel) in der FK-Definition erscheinen. Denken Sie auch daran, dass eine Tabelle mehrere Schlüssel haben kann - bezeichnet als Candidate Keys (manchmal alternative Tasten). Der Primärschlüssel ist einfach der „beste“ Schlüssel für Ihr Design / Anwendung (in der Regel des schmalste - kleinste in Byte-Größe). Wir Präfix den Namen dieser anderen eindeutigen Indizes als "AK_ {name}." - AK = Alternate Key

Was wir unter diesen Umständen tun, ist eines von zwei Dingen:

1. definieren einen synthetisierten PK eine „Identität“ -Spalte zu sein, und dann einen eindeutigen Index auf die Verbindung Schlüssel hinzufügen - also mit zwei „Schlüssel“ auf dem Tisch. Alle untergeordneten Tabellen definieren Sie dann den FK als Hinweis auf die synthetische Identität PK-Spalte.
2. Lassen Sie die Verbindung Taste gibt. Definieren sie als die PK an diesem Master-Tabelle, und stellen Sie alle FKs die gleiche Definition haben.

Generell ist es keine gute Idee, mehrere Tabellen mit derselben PK Definition haben (das heißt, PKs, die auch FKs an einem anderen Tisch sind). Ich sage „in der Regel“ - es ist wichtig, die Definition Ihrer Einheiten zu verstehen,

.

Warum also # 1? Die Frage, die ich frage mich, ob die Verbindung Schlüssel wirklich die Daten der Zeile die definiert ist? Ist das Verbundschlüssel wirklich die Definition einer Reihe oder ist es eher ein FK zu einem anderen Daten? Wenn es eines FK ist dann schaffe ich das synthetisierte PK (Identity). Ist ein Auftrag wirklich die Bücher, die ein Client besitzt? Ein Auftrag eines Clients führen kann, ein neues Buch zu besitzen -. Aber sie können nicht das gleiche sein

das synthetisierte PK Nachdem bietet ein paar mehr Auswahl auf dem Weg in den kommenden Jahren. Wenn die Beziehung in Ihrer Client_Books Tabelle ändern muss dann könnten Sie Änderungen an anderen Tabellen isolieren.

Zum Beispiel - was passiert, wenn ein Kunde besitzen, kann mehr als ein Buch zu kopieren - wie werden Sie das umsetzen? Mit dem synthetisierten Schlüssel entfernen Sie könnten einfach den eindeutigen Index für die Verbindung-Taste und lassen Sie es als einfaches FK, dann würde die Order_Details Tabelle einfach darstellen, wenn ein Kunde ihre zweite Kopie erworben hat. Wenn jedoch haben Sie die Verbindung Taste auf Bestellungen Weg genommen, dann würden Sie haben, um herauszufinden, wie Order_Detail sowie Client_Books (und alle andere FKs, die Order_Detail darauf) neu zu definieren.

Ich möchte Sie auch zu bewerten, fragen, ob ein Order_Detail ist wirklich ein Client_Book? Normalerweise ein Auftrag bewirkt, dass der Kunde in den Besitz eines neuen Buches zu kommen. Ich denke, von Bestellungen als unabhängig von der Bestandsaufnahme zu sein -. Damit die PK auf Order_Detail nicht der PK auf Client_Books sein sollte, sollte Order_Detail wahrscheinlich über eine eigene unabhängige PK

Answer 2

Sie sind zu Fuß auf einem dunklen und schmutzigen Pfad. Tun Sie dies nicht. Halten Sie sich an Best Practices -. Einen einfachen Primärschlüssel auf dem Tisch verwenden, und hat dann einen Fremdschlüssel bei Bedarf zu anderen Tabellen