以下是我拥有25年以上开发经验后得出的经验法则。

所有表都应该有一个单列主键auto 增量。 将它包含在任何意味着可更新的视图中 主键在应用程序上下文中不应该有任何意义。这意味着它不应该是SKU、帐号、员工id或对应用程序有意义的任何其他信息。它只是一个与实体相关联的唯一键。

主键由数据库用于优化目的，应用程序除了用于标识特定实体或与特定实体相关外，不应该使用主键。

始终使用单一值主键使得执行upsert非常简单。

Favor multiple indices on single columns over multi-column indices. For example, if you have a two column key, favor creating an index on each column over creating a two column index. If we create a multi-column key on firstname + lastname, we can't do indexed lookups on lastname without providing a firstname as well. Having indices on both columns allows the optimizer to perform indexed lookups on either or both columns regardless of how they are expressed in your WHERE clause. If your tables are massive, explore partitioning the table into segments based on the most prominent search criteria. If you have a table that has a significant number of Id fields in it, consider removing all except the primary key to a single table which has an id (PK), an org_id (FK to original table) and an id_type column. Create indices for all columns on the new table and relate it to the original table. In this manner, you can now perform indexed lookups of any number of ids using only a single index.

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

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

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

所有表都应该有一个主键。否则，您所拥有的就是一个HEAP——在某些情况下，这可能就是您想要的(当数据通过服务代理复制到另一个数据库或表时，会产生大量插入负载)。

对于行数较少的查找表，可以使用3 CHAR代码作为主键，因为这比INT占用的空间更少，但性能差异可以忽略不计。除此之外，我总是使用INT，除非您有一个引用表，它可能有一个由相关表的外键组成的复合主键。

我将坦率地说明我对自然键的偏好——在可能的情况下使用它们，因为它们将使您的数据库管理工作更加容易。我在公司建立了一个标准，所有的表格都有以下列:

行ID (GUID) 创造者(字符串;有一个默认的当前用户名(SUSER_SNAME()在T-SQL)) 创建(DateTime) 时间戳

行ID在每个表上都有一个唯一的键，并且在任何情况下都是每行自动生成的(并且权限阻止任何人编辑它)，并且合理地保证在所有表和数据库中是唯一的。如果任何ORM系统都需要一个ID密钥，那么可以使用这个密钥。

同时，如果可能的话，实际的PK是一个自然的关键。我的内部规则是这样的:

人-使用代理键，例如INT。如果它是内部的，那么Active Directory用户GUID是一个可以接受的选择 查找表(例如StatusCodes) -使用短的CHAR代码;它比int更容易记住，在许多情况下，纸张表格和用户也会使用它来简洁(例如，Status = "E"表示"过期"，"A"表示"已批准"，"NADIS"表示"样品中未检测到石棉")。 链接表- fk的组合(例如EventId, AttendeeId)

因此，理想情况下，您最终会得到一个自然的、人类可读的和难忘的PK，以及一个orm友好的每个表一个id的GUID。

警告:我维护的数据库倾向于100,000条记录，而不是数百万或数十亿条记录，所以如果您有使用大型系统的经验，这不利于我的建议，请随意忽略我!

我避免使用自然键的原因很简单——人为错误。虽然通常可以使用自然的唯一标识符(SSN、VIN、Account Number等)，但它们需要人工正确输入。如果您使用ssn作为主键，有人在数据输入期间调换了几个数字，并且没有立即发现错误，那么您将面临更改主键的问题。

我的主键都是由数据库程序在后台处理的，用户永远不会知道它们。

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