Navicat 博客

选择主键 - 第 1 部分 2022 年 8 月 12 日,由 Robert Gravelle 撰写

自然键与代理键

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

自然键

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

natural_key (110K)

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

productCode (202K)

代理键

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

surrogate_key (133K)

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

customerNumber (163K)

作出决定

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

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

自然键与代理键的总结

在 “选择主键”的第一部分中,我们探讨了自然主键和代理主键,并考虑了什么因素决定选择哪一种。决定一开始使用自然键还是代理键是很重要的,因为你选择哪种主键也将有助于解答一些后续问题,特别是使用代理键。

如果你想试用 Navicat 16,你可以在这里下载 14 天试用版。

Navicat 文章
频道条目
分享
文章归档