如何在 N:M 关系上创建主键？ [关闭]答案

【问题标题】：How to create a primary key on N:M relationship? [closed]如何在 N:M 关系上创建主键？ [关闭]
【发布时间】：2019-02-21 09:17:55
【问题描述】：

我正在使用 SQL Server。我有 2 张桌子。

分类

技能

那些表看起来像，

| SkillId | SkillName  | CreatedAt  |
=====================================
| 1       | programing | 01/02/2018 |

分类表

| Category| CategoryName | CreatedAt  |
=====================================
| 1       | Technical    | 01/02/2018 |

我有第三张表来映射关系。看起来，

| CategoryId | SkillId |
========================
| 1          | 4       |
| 2          | 3       |
| 2          | 4       |

我的问题是

什么是正确的数据库设计方法？

我尝试了什么

我是否要为 第三张表添加主键。是这样的吗？

| RowId | CategoryId | SkillId |
================================
| 1     | 1          | 4       |
| 2     | 2          | 3       |
| 3     | 2          | 4       |

【问题讨论】：

MySQL 和 SQL Server 是两种不同的 RDBMS，您实际使用的是哪一种？像这样的问题也很“固执”； Stack Overflow 不是讨论什么是“最佳”设计方式的地方。这不是特定的编码问题。如果你有一个编码问题，这里是什么？
第三张表确实应该有一个主键：(CategoryId, SkillId) 我没有看到为其添加生成的 ID 的好处
是时候阅读一本关于信息建模和数据库设计的教科书了。 PS不清楚你在问什么。但是，如果您在没有特定字符串/名称的情况下搜索了许多关于您的问题的清晰简洁的陈述，在考虑提出任何问题之前您应该这样做，那么您会发现这是一个常见问题解答。（也许是关于是否应该将唯一的 id 列作为额外的键添加到表中。即在技术术语中，当已经存在自然键时添加代理键。）
我想我们应该重新提出这个问题。我已经重新措辞以符合规则。有了这几个变化询问创建主键的方法是一个很好的问题。如何创建主键不是一个主要基于意见的问题，而是一个公开两种公认选项的机会：“自然键” vs “替代键”。在我看来，这是一个很好的问题。
@daniherrera 这个问题还不清楚。如果很清楚，它仍然是重复的。

标签： sql-server database-design

【解决方案1】：

你有两种方法：

自然键：由CategoryId , SkillId组成的主键
代理键：Id 作为主键 + UNIQUE Constraint for CategoryId , SkillId。

引用Wikipedia surrogate key explanation:

数据库中的代理密钥（或合成密钥、实体标识符、系统生成的密钥、数据库序列号、无事实密钥、技术密钥或任意唯一标识符）是任何一方的唯一标识符建模世界中的实体或数据库中的对象。代理键不是从应用程序数据派生的，与从应用程序数据派生的自然（或业务）键不同。

还有Wikipedia Natural key definition：

自然键（也称为业务键）是关系模型数据库设计中的一种唯一键，由现实世界中已经存在的属性组成。它用于与业务相关的列。换句话说，自然键是与该行中的属性具有逻辑关系的候选键。自然密钥有时称为域密钥。

另外，你可以了解Unique Constraint at w3schools：

UNIQUE 约束确保列中的所有值都不同。 UNIQUE 和 PRIMARY KEY 约束都为一列或一组列提供唯一性保证。 PRIMARY KEY 约束自动具有 UNIQUE 约束。但是，每个表可以有许多 UNIQUE 约束，但每个表只能有一个 PRIMARY KEY 约束。

【讨论】：