自然键和人工键是数据库社区中的一种宗教争论——请参阅本文及其链接的其他文章。我既不赞成一直使用人工钥匙，也不赞成永远不使用。我会根据具体情况做出决定，例如:

美国各州:我会使用state_code(德克萨斯州的'TX'等)，而不是德克萨斯州的state_id=1 员工:我通常会创建一个人工的employee_id，因为很难找到其他任何工作。SSN或同等的工作，但可能会有问题，如新加入谁还没有提供他/她的SSN。 员工薪资历史:(employee_id, start_date)。我不会创建一个人工的employee_salary_history_id。它能起到什么作用(除了“愚蠢的一致性”)

无论在哪里使用人工键，都应该始终在自然键上声明唯一的约束。例如，如果你必须使用state_id，但是你最好在state_code上声明一个唯一的约束，否则你最终肯定会得到:

state_id    state_code   state_name
137         TX           Texas
...         ...          ...
249         TX           Texas

从不同的字段中创建主键是没有问题的，这是一个自然键。

您可以使用Identity列(与候选字段上的唯一索引相关联)来创建代理键。

这是一个古老的讨论。在大多数情况下，我更喜欢代理键。

但是没有钥匙是没有理由的。

再保险:编辑

是的，关于这一点有很多争议:D

我没有看到任何明显的优势自然键，除了他们是自然的选择。你总是会用Name、SocialNumber或者类似的东西来思考，而不是idPerson。

代理键可以解决自然键存在的一些问题(例如传播更改)。

当你习惯了代理，它似乎更干净，更易于管理。

但最终，你会发现这只是一个品味或心态的问题。有些人用自然的钥匙能“更好地思考”，而其他人则不然。

我遵循一些规则:

Primary keys should be as small as necessary. Prefer a numeric type because numeric types are stored in a much more compact format than character formats. This is because most primary keys will be foreign keys in another table as well as used in multiple indexes. The smaller your key, the smaller the index, the less pages in the cache you will use. Primary keys should never change. Updating a primary key should always be out of the question. This is because it is most likely to be used in multiple indexes and used as a foreign key. Updating a single primary key could cause of ripple effect of changes. Do NOT use "your problem primary key" as your logic model primary key. For example passport number, social security number, or employee contract number as these "natural keys" can change in real world situations. Make sure to add UNIQUE constraints for these where necessary to enforce consistency.

关于代理键和自然键，我参考了上面的规则。如果自然键很小并且永远不会改变，则可以将其用作主键。如果自然键很大或可能改变，我使用代理键。如果没有主键，我仍然会创建一个代理键，因为经验表明，您总是会向模式添加表，并希望在适当的位置放置一个主键。

除了这些好答案，我想分享一篇我刚读过的好文章，伟大的主键辩论。

这里引用几点:

开发人员在为每个表选择主键时必须应用一些规则:

主键必须唯一地标识每条记录。 记录的主键值不能为空。 在创建记录时，主键-值必须存在。 主键必须保持稳定—您不能更改主键字段。 主键必须紧凑且包含尽可能少的属性。 主键值不能更改。

自然键(倾向于)打破规则。代理键符合规则。(你最好通读那篇文章，它值得你花时间!)

如果你真的想阅读关于这个古老争论的所有内容，可以在Stack Overflow上搜索“自然键”。你应该能拿到几页结果。

自然键和人工键是数据库社区中的一种宗教争论——请参阅本文及其链接的其他文章。我既不赞成一直使用人工钥匙，也不赞成永远不使用。我会根据具体情况做出决定，例如:

美国各州:我会使用state_code(德克萨斯州的'TX'等)，而不是德克萨斯州的state_id=1 员工:我通常会创建一个人工的employee_id，因为很难找到其他任何工作。SSN或同等的工作，但可能会有问题，如新加入谁还没有提供他/她的SSN。 员工薪资历史:(employee_id, start_date)。我不会创建一个人工的employee_salary_history_id。它能起到什么作用(除了“愚蠢的一致性”)

无论在哪里使用人工键，都应该始终在自然键上声明唯一的约束。例如，如果你必须使用state_id，但是你最好在state_code上声明一个唯一的约束，否则你最终肯定会得到:

state_id    state_code   state_name
137         TX           Texas
...         ...          ...
249         TX           Texas