数据库设计中如何选择主键（自然键或代理键）| Part 1

自然键与代理键

身为数据库设计人员，你将面临的首要决定是你的表应使用哪种主键（PK）。如果你询问任何每天处理数据库的人，无论是数据库管理员、开发人员还是测试人员，你都会得到无数的意见和理由。使解决问题的障碍更加复杂的是，没有一种万能的解决方案。有鉴于此，本系列将介绍支持和反对不同类型 PK 的一些原因。在所有这些原因的某处，将会引导你找出 PK 的最佳类型，以满足你的组织需求。在第一部分中，我们将比较两种基本类型的 PK：自然键和代理键。稍后，我们将讨论是否使用数据库自动递增功能，以及哪些数据类型（如果有）是最好的 PK。

自然键

自然键是由表中已存在的一个或多个列组成的（例如，它们是数据模型中实体的属性），用于唯一标识表中的一条记录。由于这些列是实体的属性，因此它们本质上具有业务意义。以下是 Navicat Premium 16 的表设计器中有自然键的表示例。我们可以通过 “键”列中的钥匙图标轻松找到主键：

查看一下数据，我们可以知道 productCode 是有业务义意的：

代理键

代理键（或合成键、伪键、实体标识符、非事实型键、技术键等！）是由系统生成的（GUID、序列、唯一标识符等）值，没有业务意义，用于唯一标识表中的记录。键本身也可以由一列或多列（即复合键）组成。我们可以看到在同一个数据库的表中有一个代理键，定义了一个customerNumber 列作为表的 PK：

虽然该列不是自动递增，但它是一个与客户实体无关的数字字段：

作出决定

那么，为什么一个表使用自然键，而另一个表使用代理键呢？

产品有一个唯一的库存编号是很常见的，这是一个理想的PK。而添加一个额外的数字键只会浪费磁盘空间，并且几乎肯定需要在 productCode 列上添加一个用于搜索的额外索引。但另一方面，客户通常不会有一个唯一标识符。若你必须在数据库中辨识特定客户，可能需要一个长得惊人的列列表。因此，分配一个数字代理键来索引表中每一列通常要容易得多。