Est-ce bien d'avoir une clé étrangère comme clé primaire?
j'ai table" User "(Nom d'utilisateur, mot de passe) et table" Profile " (Profil, sexe, date de naissance,...). Actuellement j'utilise cette approche: chaque enregistrement de profil a un champ nommé "userId" comme clé étrangère qui renvoie à la table D'utilisateur. Lorsqu'un utilisateur s'enregistre, son Profil est automatiquement créé. Je suis confus avec la suggestion de mon ami: avoir le champ " userId "comme clé étrangère et primaire et supprimer le champ" profileId". Quelle approche est la meilleure ?
7 réponses
les clés étrangères sont presque toujours des "doublons autorisés", ce qui les rendrait inappropriées comme clés primaires.
à la Place, trouver un champ qui identifie uniquement chaque enregistrement dans la table, ou ajouter un nouveau champ (soit un entier auto-incrémentant ou un GUID) pour agir comme la clé primaire.
la seule exception à cette règle sont les tables avec une relation un-à-un, où la clé étrangère et la clé primaire de la table liée sont une seule et même.
les clés primaires doivent toujours être uniques, les clés étrangères doivent permettre des valeurs non uniques si la table est une relation de un à plusieurs. Il est parfaitement correct d'utiliser une clé étrangère comme clé primaire si la table est reliée par une relation un-à-un, pas une relation un-à-plusieurs. Si vous voulez le même enregistrement utilisateur la possibilité d'avoir plus de 1 enregistrement de profil, aller avec une clé primaire distincte, sinon coller avec ce que vous avez.
Il est généralement considéré comme une mauvaise pratique d'avoir une relation. C'est parce que vous pourriez juste avoir les données représentées dans un tableau et obtenir le même résultat.
cependant, il y a des cas où vous ne pouvez pas apporter ces changements au tableau que vous référencez. Dans ce cas, il n'y a aucun problème à utiliser la clé étrangère comme clé primaire. Il pourrait être utile d'avoir une clé composite constituée d'une clé primaire unique incrémentant automatiquement et la clé étrangère.
je travaille actuellement sur un système où les utilisateurs peuvent se connecter et générer un code d'enregistrement à utiliser avec une application. Pour des raisons que je ne vais pas aller dans je suis incapable d'ajouter simplement les colonnes nécessaires à la table des utilisateurs. Donc je vais suivre une voie de un à un avec la table de codes.
Oui, une clé étrangère peut être une clé primaire dans le cas de relations entre ces tables
Je ne ferais pas ça. Je garderais le profileID comme clé principale de la table Profile
une clé étrangère n'est qu'une contrainte de référence entre deux tables
on pourrait soutenir qu'une clé primaire est nécessaire comme cible de toute clé étrangère qui s'y réfère à partir d'autres tables. Une clé étrangère est un ensemble d'une ou plusieurs colonnes dans une table (pas nécessairement une clé candidate, sans parler de la clé primaire de la table) qui peut tenir la valeur(s) trouvé dans la colonne de clé primaire(s) d'une autre table. Donc on doit avoir une clé primaire pour correspondre à la clé étrangère. Ou devons-nous? Le seul but de la clé primaire dans la paire clé primaire/clé étrangère est de fournir une jointure sans ambiguïté - pour maintenir l'intégrité de référence par rapport à la table "étrangère" qui détient la clé primaire référencée. Cela garantit que la valeur à laquelle la clé étrangère se réfère sera toujours valide (ou nulle, si elle est autorisée).
Cela dépend de l'entreprise et du système.
si votre userId est unique et le sera tout le temps, vous pouvez utiliser userId comme votre clé principale. Mais si vous voulez étendre votre système, cela rendra les choses difficiles. Je vous conseille d'ajouter une clé étrangère dans l'utilisateur de table pour faire une relation avec le profil de table au lieu d'ajouter une clé étrangère dans le profil de table.
Oui, il est légal d'avoir une clé primaire étant une clé étrangère. C'est une construction rare, mais elle s'applique pour:
-
1:1 rapport. Les deux tables ne peuvent pas être fusionnées en une en raison de permissions et de privilèges différents s'appliquent seulement au niveau de la table (à partir de 2017, une telle base de données serait étrange).
-
un rapport de 1:0..1 rapport. Profil peut exister ou non, selon le type d'utilisateur.
-
la performance est un problème, et la conception agit comme une partition: la table de profil est rarement accessible, hébergé sur un disque séparé ou a une politique de sharding différente par rapport à la table des utilisateurs. Ne serait pas logique si le stockage de soulignement est colonnaire.