NM关系中是否复合主键？
假设我们有 3 个表（实际上我现在有 2 个，但这个例子可能会更好地说明这个想法）：
[Person]
- ID：int，主键
- 名称：nvarchar(xx)
[组]
- ID：int，主键
- 名称：nvarchar(xx)
[角色]
- ID：int，主键
- 名称：nvarchar(xx)
[PersonGroupRole]
- Person_ID：int，是否是主要复合？
- Group_ID：int，是否是主要复合？
- Role_ID：int ，是否是主组合？
关系 PersonGroupRole 中的 3 个 ID 中的任何一个是否应该标记为主键，或者是否应该将它们全部组合成一个复合？？做或不做的真正好处是什么？
据我所知，我无论如何都可以加入，所以 Person JOIN PersonGroupRole JOIN Group 告诉我哪些人在哪些组中等等。
我将在 SQL-express 和 SQL-server 之上使用 LINQ/C#/.NET，所以如果有关于语言/SQL 的任何原因可能会使选择更加明确，这就是我询问的平台。
期待看到弹出的答案，因为我在制作组合键/索引时多次想到了这些主键/索引。
编辑：
好的，我现在可以看到这个问题被误解了。
问题是，将 PersonGroupRole 中的三个 ID 标记为主键以用于索引是否有意义。这是否会增加连接三个表中每一个的额外速度，或者它们是否应该在 PersonGroupRole 表中保留没有 PRIMARY KEY 而仅在单独的表中成为 Primary 。
抱歉，关于混乱。会尽力更好地解释我的问题。
Lets say we have 3 tables (actually I have 2 at the moment, but this example might illustrate the thought better):
[Person]
- ID: int, primary key
- Name: nvarchar(xx)
[Group]
- ID: int, primary key
- Name: nvarchar(xx)
[Role]
- ID: int, primary key
- Name: nvarchar(xx)
[PersonGroupRole]
- Person_ID: int, PRIMARY COMPOSITE OR NOT?
- Group_ID: int, PRIMARY COMPOSITE OR NOT?
- Role_ID: int, PRIMARY COMPOSITE OR NOT?
Should any of the 3 ID's in the relation PersonGroupRole be marked as PRIMARY key or should they all 3 be combined into one composite?? whats the real benefit of doing it or not?
I can join anyways as far as I know, so Person JOIN PersonGroupRole JOIN Group gives me which persons are in which Groups etc.
I will be using LINQ/C#/.NET on top of SQL-express and SQL-server, so if there is any reasons regarding language/SQL that might make the choice more clear, that's the platform I ask about.
Looking forward to see what answers pops up, as I have thought of these primary keys/indexes many times when making combined ones.
EDIT:
Okay, the question was to be misunderstood I can see now.
The question is about, if it makes any sense to mark the three ID's in PersonGroupRole as PRIMARY KEYS for index purpose. Will this add extra speed for joining with each of the three tables, or should they stay without PRIMARY KEY in the PersonGroupRole table and only be Primary in the separate tables.
Sorry, about the confusion. Will try to explain my questions better.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
组合键清楚地标识每一行（假设一个人不能在同一组中具有相同的角色两次），因此它是一个很好的主键。
您是否实际上将其声明为物理主键取决于您正在使用的工具以及这些表周围的数据库的其余部分。您是否还有很多其他表与此表有 FK？如果是这样，那么代理键可能是合适的。
The composite key distinctly identifies each row (assuming that a person can't have the same role in the same group twice), so it makes for a good primary key.
Whether you actually declare that as your physical primary key though depends on the tools that you're using and the rest of the database around these tables. Will you have a lot of other tables that have FKs to this table? If so, then a surrogate key might be in order.
这取决于关系：
很可能，您需要更多的表和 4NF 或 5NF 来捕获此
示例在这里，但我拥有的最好的链接现在是一些蹩脚的链接页面，抱歉。
另一个稍微描述了我的问题
It depends on what the relationships are:
Most likely, you need more tables and 4NF or 5NF to capture this
Example here, but the best link I had is now some crappy link page sorry.
Another that describes my questions somewhat
这个问题似乎是基于对密钥的根本误解。应该清楚的是，将其中一列设为键而不是所有三列上的复合键将完全改变该表的含义和潜在用途。对业务需求的分析以及对您正在建模的现实世界情况的理解应该可以确定哪些列是独特的。不幸的是，这个问题没有说明数据模型的实际需求，所以我认为它无法以任何有意义的方式回答。
The question seems to be based on a fundamental misunderstanding about keys. It ought to be clear that making one of those columns a key versus a compound key on all three of them would entirely change the meaning and potential uses of the table. Analysis of business requirements and an understanding of the real world situation that you are modelling ought to determine what columns are unique. Unfortunately the question says nothing about what is actually required of the data model so I think it is unanswerable in any meaningful way.