这只是对一些经常被忽视的东西的额外评论。有时不使用单个代理键作为主键对子表有好处。假设我们有一种设计，允许您在一个数据库中运行多个公司(可能是一个托管解决方案，或者其他什么)。

假设我们有这些表和列:

Company:
  CompanyId   (primary key)

CostCenter:
  CompanyId   (primary key, foreign key to Company)
  CostCentre  (primary key)

CostElement
  CompanyId   (primary key, foreign key to Company)
  CostElement (primary key)

Invoice:
  InvoiceId    (primary key)
  CompanyId    (primary key, in foreign key to CostCentre, in foreign key to CostElement)
  CostCentre   (in foreign key to CostCentre)
  CostElement  (in foreign key to CostElement)

以防最后一点说不通，发票。CompanyId是两个外键的一部分，一个指向CostCentre表，另一个指向CostElement表。主键是(InvoiceId, CompanyId)。

在这个模型中，不可能搞砸并引用来自一个公司的CostElement和来自另一个公司的CostCentre。如果在CostElement和CostCentre表上使用一个代理键作为主键，并且在Invoice表中没有外键关系，那么它就是。

搞砸的机会越少越好。

表应该一直有一个主键。如果没有，它应该是一个自动递增字段。

有时人们会省略主键，因为他们要传输大量数据，这可能会减慢(取决于数据库)进程。但是，它应该加在它之后。

一些关于链接表的评论，这是正确的，这是一个例外，但是字段应该是FK以保持完整性，并且在某些情况下，如果链接中的重复没有被授权，这些字段也可以是主键…但是要保持简单的形式，因为异常在编程中经常出现，所以应该提供主键来保持数据的完整性。

对我来说，自然键和人工键的区别在于数据库中需要多少业务逻辑。社会安全号码(SSN)就是一个很好的例子。

“我的数据库中的每个客户都将而且必须有SSN。”搞定，把它设为主键，搞定。只要记住，当你的业务规则改变时，你就完蛋了。

我自己不喜欢自然键，因为我有改变业务规则的经验。但是如果您确定它不会改变，那么它可能会阻止一些关键的连接。

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

这里引用几点:

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

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

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

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

我遵循一些规则:

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.

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