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

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

GUID可以用作主键，但是您需要创建正确类型的GUID，这样它才能正常运行。

您需要生成COMB guid。一篇关于它和性能统计的好文章是 guid作为主键的代价。

此外，在SQL中构建COMB guid的一些代码是在Uniqueidentifier vs identity(存档)中。

我怀疑原始数据结构的设计者需要Steven A. Lowe的卷起报纸疗法。

顺便说一句，guid作为主键可能会影响性能。我不推荐。

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

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

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

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

美国各州:我会使用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

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

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

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