Est-il possible d'avoir une clé étrangère comme clé primaire ?

Question

J'ai deux tableaux :

• Utilisateur (nom d'utilisateur, mot de passe)
• Profil (profileId, sexe, date de naissance, ...)

Actuellement, j'utilise l'approche suivante : chaque enregistrement de profil possède un champ appelé "userId" sous la forme suivante clé étrangère qui renvoie au tableau des utilisateurs. Lorsqu'un utilisateur s'inscrit, son enregistrement de profil est automatiquement créé.

Je ne comprends pas bien la suggestion de mon ami : faire en sorte que le champ "userId" soit le champ étranger y primaire et supprimez le champ "profileId". Quelle est la meilleure approche ?

Answer 1

Je ne le ferais pas. Je garderais le profileID comme clé primaire de la table Profile

Une clé étrangère est simplement une contrainte référentielle entre deux tables.

On pourrait affirmer qu'une clé primaire est nécessaire en tant que cible de toutes les clés étrangères qui s'y réfèrent à partir d'autres tables. Une clé étrangère est un ensemble d'une ou plusieurs colonnes d'une table (pas nécessairement une clé candidate, et encore moins la clé primaire de cette table) qui peut contenir la ou les valeurs trouvées dans la ou les colonnes de la clé primaire d'une autre table. Nous devons donc avoir une clé primaire correspondant à la clé étrangère. Ou devons-nous le faire ? Le seul objectif de la clé primaire dans la paire clé primaire/clé étrangère est de fournir une jointure sans ambiguïté - de maintenir l'intégrité référentielle 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 fait référence sera toujours valide (ou nulle, si cela est autorisé).

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

Answer 2

Cela dépend de l'entreprise et du système.

Si l'identifiant de l'utilisateur est unique et le sera toujours, vous pouvez utiliser l'identifiant de l'utilisateur comme clé primaire. Mais si vous souhaitez un jour étendre votre système, cela rendra les choses plus difficiles. Je vous conseille d'ajouter une clé étrangère dans la table user pour établir une relation avec la table profile au lieu d'ajouter une clé étrangère dans la table profile.

Answer 3

Réponse courte : DEPENDS.... Dans ce cas particulier, cela peut être une bonne chose. Toutefois, les experts recommandent de ne pas le faire dans presque tous les cas, y compris le vôtre.

Pourquoi ?

Les clés sont rarement uniques dans les tables lorsqu'elles sont étrangères (issues d'une autre table) à la table en question. Par exemple, l'identifiant d'un article peut être unique dans une table ITEMS, mais pas dans une table ORDERS, puisque le même type d'article existera très probablement dans une autre commande. De même, les identifiants de commande peuvent être uniques (éventuellement) dans la table ORDERS, mais pas dans une autre table comme ORDER_DETAILS où une commande avec plusieurs articles peut exister et où, pour interroger un article particulier dans une commande particulière, vous avez besoin de la concaténation de deux FK (order_id et item_id) en tant que PK pour cette table.

Je ne suis pas un expert en matière de bases de données, mais si vous pouvez justifier logiquement l'utilisation d'une valeur générée automatiquement comme PK, c'est ce que je ferais. Si ce n'est pas pratique, une concaténation de deux (ou peut-être plus) FK pourrait servir de PK. MAIS, je ne vois aucun cas où une seule valeur FK peut être justifiée en tant que PK.

Answer 4

Cela ne s'applique pas totalement au cas de la question, mais comme je suis tombé sur cette question en cherchant d'autres informations et en lisant certains commentaires, je peux dire qu'il est possible de n'avoir qu'un FK dans une table et d'obtenir des valeurs uniques. Vous pouvez utiliser une colonne qui a des classes, qui ne peut être assignée qu'une seule fois, cela fonctionne presque comme un ID, cependant cela pourrait être fait dans le cas où vous voulez utiliser une valeur catégorielle unique qui distingue chaque enregistrement.