webentwicklung-frage-antwort-db.com.de

Ist es in Ordnung, einen Fremdschlüssel als Primärschlüssel zu haben?

Ich habe zwei Tische:

  • Benutzer (Benutzername, Passwort)
  • Profil (Profil-ID, Geschlecht, Geburtsdatum, ...)

Derzeit verwende ich diesen Ansatz: Jeder Profildatensatz hat ein Feld mit dem Namen "userId" als Fremdschlüssel, das auf die Benutzertabelle verweist. Wenn sich ein Benutzer registriert, wird sein Profildatensatz automatisch erstellt.

Ich bin mit meinem Vorschlag eines Freundes verwechselt: Das Feld "userId" als foreign und primary Schlüssel verwenden und das Feld "profileId" löschen. Welcher Ansatz ist besser?

80
Duc Tran

Fremdschlüssel sind fast immer "Duplikate zulassen", was sie als Primärschlüssel ungeeignet macht.

Suchen Sie stattdessen ein Feld, das jeden Datensatz in der Tabelle eindeutig identifiziert, oder fügen Sie ein neues Feld hinzu (entweder eine automatisch inkrementierende Ganzzahl oder eine GUID), das als Primärschlüssel fungiert.

Die einzige Ausnahme bilden Tabellen mit einer eins zu eins Beziehung, Dabei sind der Schlüssel foreign und der Schlüssel primary der verknüpften Tabelle ein und dasselbe.

107
Robert Harvey

Primärschlüssel müssen immer eindeutig sein, Fremdschlüssel müssen nicht eindeutige Werte zulassen, wenn es sich bei der Tabelle um eine Eins-zu-Viele-Beziehung handelt. Es ist völlig in Ordnung, einen Fremdschlüssel als Primärschlüssel zu verwenden, wenn die Tabelle durch eine Eins-zu-Eins-Beziehung und nicht durch eine Eins-zu-Viele-Beziehung verbunden ist. Wenn Sie möchten, dass derselbe Benutzerdatensatz die Möglichkeit hat, mehr als einen zugehörigen Profildatensatz zu haben, verwenden Sie einen separaten Primärschlüssel. Andernfalls bleiben Sie bei Ihren Angaben.

31
kotekzot

Es wird allgemein als schlechte Praxis angesehen, eine Eins-zu-Eins-Beziehung zu haben. Dies liegt daran, dass Sie die Daten nur in einer Tabelle darstellen und dasselbe Ergebnis erzielen können.

Es gibt jedoch Fälle, in denen Sie diese Änderungen möglicherweise nicht an der Tabelle vornehmen können, auf die Sie verweisen. In diesem Fall ist die Verwendung des Fremdschlüssels als Primärschlüssel kein Problem. Es kann hilfreich sein, einen zusammengesetzten Schlüssel zu haben, der aus einem automatisch inkrementierenden eindeutigen Primärschlüssel und dem Fremdschlüssel besteht.

Ich arbeite derzeit an einem System, in dem sich Benutzer anmelden und einen Registrierungscode für eine App generieren können. Aus Gründen, auf die ich nicht näher eingehen möchte, kann ich die erforderlichen Spalten nicht einfach zur Benutzertabelle hinzufügen. Also gehe ich mit der Codetabelle eine Eins-zu-Eins-Route hinunter.

3
Tshsmith

Ja, bei einer Eins-zu-Eins-Beziehung zwischen diesen Tabellen kann ein Fremdschlüssel ein Primärschlüssel sein

3
Riaj Ferdous

Ja, es ist legal, dass ein Primärschlüssel ein Fremdschlüssel ist. Dies ist ein seltenes Konstrukt, aber es gilt für:

  • eine 1: 1 Beziehung. Die beiden Tabellen können nicht in einer zusammengeführt werden, da unterschiedliche Berechtigungen und Privilegien nur auf Tabellenebene gelten (ab 2017 wäre eine solche Datenbank ungerade).

  • eine 1: 0..1 Beziehung. Das Profil kann je nach Benutzertyp vorhanden sein oder nicht.

  • die Leistung ist ein Problem, und das Design fungiert als Partition: Auf die Profiltabelle wird selten zugegriffen, sie wird auf einem separaten Datenträger gehostet oder sie hat eine andere Sharding-Richtlinie als die Benutzertabelle. Wäre nicht sinnvoll, wenn die Unterstreichung spaltenweise ist.

3
user9016329

Ich würde das nicht tun. Ich würde den profileID als Primärschlüssel der Tabelle Profile behalten

Ein Fremdschlüssel ist nur eine referenzielle Einschränkung zwischen zwei Tabellen

Man könnte argumentieren, dass ein Primärschlüssel als Ziel von Fremdschlüsseln erforderlich ist, die aus anderen Tabellen darauf verweisen. Ein Fremdschlüssel ist ein Satz von einer oder mehreren Spalten in einer Tabelle (nicht notwendigerweise ein Kandidatenschlüssel, geschweige denn der Primärschlüssel dieser Tabelle), der die Werte enthalten kann, die in den Primärschlüsselspalten einiger enthalten sind andere Tabelle. Wir müssen also einen Primärschlüssel haben, der mit dem Fremdschlüssel übereinstimmt. Oder müssen wir? Der einzige Zweck des Primärschlüssels im Primärschlüssel/Fremdschlüssel-Paar ist die Bereitstellung einer eindeutigen Verknüpfung, um die referenzielle Integrität in Bezug auf die "Fremd" -Tabelle aufrechtzuerhalten, die den referenzierten Primärschlüssel enthält. Dies stellt sicher, dass der Wert, auf den sich der Fremdschlüssel bezieht, immer gültig ist (oder null, falls zulässig).

http://www.aisintl.com/case/primary_and_foreign_key.html

2

Es kommt auf das Geschäft und das System an.

Wenn Ihre Benutzer-ID eindeutig ist und die ganze Zeit eindeutig bleibt, können Sie die Benutzer-ID als Primärschlüssel verwenden. Wenn Sie Ihr System jedoch jemals erweitern möchten, wird dies die Dinge erschweren. Ich rate Ihnen, einen Fremdschlüssel im Tabellenbenutzer hinzuzufügen, um eine Beziehung zum Tabellenprofil herzustellen, anstatt einen Fremdschlüssel im Tabellenprofil hinzuzufügen.

1
Vincent Cai

Kurze Antwort: ABHÄNGIGKEITEN .... In diesem speziellen Fall könnte es in Ordnung sein. Experten werden jedoch fast jedes Mal davon abraten; einschließlich Ihres Falls.

Warum?

Schlüssel sind in Tabellen selten eindeutig, wenn sie der betreffenden Tabelle fremd sind (von einer anderen Tabelle stammen). Beispielsweise kann eine Artikel-ID in einer ITEMS-Tabelle eindeutig sein, jedoch nicht in einer ORDERS-Tabelle, da derselbe Artikeltyp höchstwahrscheinlich in einer anderen Reihenfolge vorhanden ist. Ebenso können Bestell-IDs in der Tabelle ORDERS eindeutig (möglicherweise) sein, jedoch nicht in einer anderen Tabelle wie ORDER_DETAILS, in der eine Bestellung mit mehreren Positionen vorhanden sein kann. Um eine Abfrage für eine bestimmte Position in einer bestimmten Reihenfolge durchzuführen, müssen zwei verkettet werden FK (order_id und item_id) als PK für diese Tabelle.

Ich bin kein DB-Experte, aber wenn Sie logisch begründen können, einen automatisch generierten Wert als Ihre PK zu haben, würde ich das tun. Wenn dies nicht praktikabel ist, kann eine Verkettung von zwei (oder mehr) FK als PK dienen. ABER ich kann mir keinen Fall vorstellen, in dem ein einziger FK-Wert als PK gerechtfertigt werden kann.

0
hfontanez