Clés primaires composites en relation NM ou non?

Disons que nous avons 3 tables (en fait j'en ai 2 en ce moment, mais cet exemple pourrait mieux illustrer la pensée):

[La personne]

  • ID: int, key primaire
  • Nom: nvarchar (xx)

[Groupe]

  • ID: int, key primaire
  • Nom: nvarchar (xx)

[Rôle]

  • ID: int, key primaire
  • Nom: nvarchar (xx)

[PersonGroupRole]

  • Person_ID: int, COMPOSITE PRIMAIRE OU NON?
  • Group_ID: int, COMPOSITE PRIMAIRE OU NON?
  • Role_ID: int, COMPOSITE PRIMAIRE OU NON?

Est-ce que l'un des 3 identifiants de la relation PersonGroupRole doit être marqué comme key PRIMARY ou doivent-ils tous être combinés en un seul composite? quel est le véritable avantage de le faire ou non?

Je peux me joindre de toute façon, autant que je sache, donc Person JOIN PersonGroupRole JOIN Group me donne les personnes dans quels groupes etc.

J'utiliserai LINQ / C # /. NET en plus de SQL-express et SQL-server, donc s'il y a des raisons de langage / SQL qui pourraient rendre le choix plus clair, c'est la plate-forme que je request.

J'attends avec impatience de voir quelles réponses apparaissent, car j'ai souvent pensé à ces clefs / index primaires en faisant des combinaisons.

MODIFIER:

D'accord, la question était d'être mal compris, je peux voir maintenant.

La question est à propos, si cela a un sens de marquer les trois ID dans PersonGroupRole comme PRIMARY KEYS à des fins d'index. Cela appenda-t-il une vitesse supplémentaire pour se joindre à chacune des trois tables, ou devrait-il restr sans PRIMARY KEY dans la table PersonGroupRole et seulement être Primary dans les tables séparées.

Désolé, à propos de la confusion. Je vais essayer d'expliquer mieux mes questions.

La key composite identifie distinctement chaque ligne (en supposant qu'une personne ne peut pas avoir deux fois le même rôle dans le même groupe), ce qui en fait une bonne key primaire.

Que vous déclariez réellement que votre key primaire physique dépende des outils que vous utilisez et du rest de la database autour de ces tables. Auriez-vous beaucoup d'autres tables qui ont des FK à cette table? Si oui, une key de substitution pourrait être en ordre.

Cela dépend de ce que sont les relations:

  • Une personne peut-elle être dans plus d'un groupe?
  • Avoir plusieurs rôles?
  • Le rôle / groupe 1: 1 est-il associé à plusieurs personnes dans cette combinaison?
  • etc

Très probablement, vous avez besoin de plus de tables et 4NF ou 5NF pour capturer cette

Exemple ici , mais le meilleur lien que j'ai eu est maintenant une page de lien merdique désolé. Un autre qui décrit un peu mes questions

La question semble reposer sur un malentendu fondamental à propos des keys. Il devrait être clair que le fait de faire de l'une de ces colonnes une key par rapport à une key composée pour chacune d'entre elles changerait complètement la signification et les utilisations potentielles du tableau. L'parsing des besoins de l'entreprise et une compréhension de la situation réelle que vous modélisez devraient déterminer quelles colonnes sont uniques. Malheureusement, la question ne dit rien sur ce qui est réellement requirejs du model de données, donc je pense qu'il est impossible de répondre de façon significative.