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

假设我们有这些表和列:

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表中没有外键关系，那么它就是。

搞砸的机会越少越好。

我寻找自然主键，并尽可能地使用它们。

如果找不到自然的键，我更喜欢GUID而不是INT++，因为SQL Server使用树，总是在树的末尾添加键是不好的。

在多对多耦合的表上，我使用外键的复合主键。

因为我很幸运使用SQL Server，我可以用分析器和查询分析器研究执行计划和统计数据，并很容易地发现我的键是如何执行的。

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

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

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

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

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

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

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

主键有什么特别之处?

模式中表的用途是什么?表中键的作用是什么?主键有什么特别之处?围绕主键的讨论似乎忽略了一点，即主键是表的一部分，而表是模式的一部分。对表和表关系最有利的应该驱动所使用的键。

Tables (and table relationships) contain facts about information you wish to record. These facts should be self-contained, meaningful, easily understood, and non-contradictory. From a design perspective, other tables added or removed from a schema should not impact on the table in question. There must be a purpose for storing the data related only to the information itself. Understanding what is stored in a table should not require undergoing a scientific research project. No fact stored for the same purpose should be stored more than once. Keys are a whole or part of the information being recorded which is unique, and the primary key is the specially designated key that is to be the primary access point to the table (i.e. it should be chosen for data consistency and usage, not just insert performance).

ASIDE: The unfortunately side effect of most databases being designed and developed by application programmers (which I am sometimes) is that what is best for the application or application framework often drives the primary key choice for tables. This leads to integer and GUID keys (as these are simple to use for application frameworks) and monolithic table designs (as these reduce the number of application framework objects needed to represent the data in memory). These application driven database design decisions lead to significant data consistency problems when used at scale. Application frameworks designed in this manner naturally lead to table at a time designs. “Partial records” are created in tables and data filled in over time. Multi-table interaction is avoided or when used causes inconsistent data when the application functions improperly. These designs lead to data that is meaningless (or difficult to understand), data spread over tables (you have to look at other tables to make sense of the current table), and duplicated data.

It was said that primary keys should be as small as necessary. I would says that keys should be only as large as necessary. Randomly adding meaningless fields to a table should be avoided. It is even worse to make a key out of a randomly added meaningless field, especially when it destroys the join dependency from another table to the non-primary key. This is only reasonable if there are no good candidate keys in the table, but this occurrence is surely a sign of a poor schema design if used for all tables.

It was also said that primary keys should never change as updating a primary key should always be out of the question. But update is the same as delete followed by insert. By this logic, you should never delete a record from a table with one key and then add another record with a second key. Adding the surrogate primary key does not remove the fact that the other key in the table exists. Updating a non-primary key of a table can destroy the meaning of the data if other tables have a dependency on that meaning through a surrogate key (e.g. a status table with a surrogate key having the status description changed from ‘Processed’ to ‘Cancelled’ would definitely corrupt the data). What should always be out of the question is destroying data meaning.

Having said this, I am grateful for the many poorly designed databases that exist in businesses today (meaningless-surrogate-keyed-data-corrupted-1NF behemoths), because that means there is an endless amount of work for people that understand proper database design. But on the sad side, it does sometimes make me feel like Sisyphus, but I bet he had one heck of a 401k (before the crash). Stay away from blogs and websites for important database design questions. If you are designing databases, look up CJ Date. You can also reference Celko for SQL Server, but only if you hold your nose first. On the Oracle side, reference Tom Kyte.