自然键与代理键
身为数据库设计人员，你将面临的首要决定是你的表应使用哪种主键（PK）。如果你询问任何每天处理数据库的人，无论是数据库管理员、开发人员还是测试人员，你都会得到无数的意见和理由。使解决问题的障碍更加复杂的是，没有一种万能的解决方案。有鉴于此，本系列将介绍支持和反对不同类型 PK 的一些原因。在所有这些原因的某处，将会引导你找出 PK 的最佳类型，以满足你的组织需求。在第一部分中，我们将比较两种基本类型的 PK：自然键和代理键。稍后，我们将讨论是否使用数据库自动递增功能，以及哪些数据类型（如果有）是最好的 PK。
自然键
自然键是由表中已存在的一个或多个列组成的（例如，它们是数据模型中实体的属性），用于唯一标识表中的一条记录。由于这些列是实体的属性，因此它们本质上具有业务意义。以下是 Navicat Premium 16 的表设计器中有自然键的表示例。我们可以通过 “键”列中的钥匙图标轻松找到主键：
查看一下数据，我们可以知道 productCode 是有业务义意的：
代理键
代理键（或合成键、伪键、实体标识符、非事实型键、技术键等！）是由系统生成的（GUID、序列、唯一标识符等）值，没有业务意义，用于唯一标识表中的记录。键本身也可以由一列或多列（即复合键）组成。 我们可以看到在同一个数据库的表中有一个代理键，定义了一个customerNumber 列作为表的 PK：
虽然该列不是自动递增，但它是一个与客户实体无关的数字字段：
作出决定
那么，为什么一个表使用自然键，而另一个表使用代理键呢？
产品有一个唯一的库存编号是很常见的，这是一个理想的PK。而添加一个额外的数字键只会浪费磁盘空间，并且几乎肯定需要在 productCode 列上添加一个用于搜索的额外索引。但另一方面，客户通常不会有一个唯一标识符。若你必须在数据库中辨识特定客户，可能需要一个长得惊人的列列表。因此，分配一个数字代理键来索引表中每一列通常要容易得多。
自然键与代理键的总结
在 “选择主键”的第一部分中，我们探讨了自然主键和代理主键，并考虑了什么因素决定选择哪一种。决定一开始使用自然键还是代理键是很重要的，因为你选择哪种主键也将有助于解答一些后续问题，特别是使用代理键。
如果你想试用 Navicat 16，你可以在这里下载 14 天试用版。
