使用 uuid 作为主键和/或代理键？答案

【问题标题】：Use uuid as primary and/or as surrogate key?使用 uuid 作为主键和/或代理键？
【发布时间】：2011-03-15 15:35:07
【问题描述】：

我们需要将 UUID 添加到我们的大多数对象和数据库表中。

除了序列生成的代理键之外，您会使用 UUID 作为代理键还是自然键，即使用私有代理键并另外添加列/属性来保存 UUID？

我看到它经常直接用作代理/主键。不知怎的，我不喜欢这个主意。

人们可能会将 UUID 视为自然键，因为它应该是具有全局意义的唯一标识符，就像任何其他自然键一样，独立于系统的特定实现，即如果您将数据移动到另一个系统中，UUID 必须保持不变，而根据定义，代理键没有真正和持久的含义。

也许我应该澄清更多：假设我们有一个 Account 表。传统上会有一些内部代理键和一个由帐号组成的自然键（如打印在帐户报表等上）。

虽然 UUID 不像帐号那样“可读”，但我认为 UUID 更像是自然密钥，因为它可以起到与帐号相同的作用：以唯一且不变的方式引用特定帐户方式。（传统的）代理键永远不会出现在系统之外，因为它是完全私有的并且可以随时更改，因此不能存在任何外部引用。

从这个意义上说，UUID 不是典型的代理键 (?)。

【问题讨论】：

自然键是根据数据创建键而形成的。 UUID 是代理键，只是全局唯一的代理。
@andrey：一旦选择了特定类型的代理键，就很难改变。我知道我们将有数百万个对我们所有“帐户”的引用，即大外键会大大增加数据库大小，需要更多 I/O，读取更多物理文件块等。优化不是必然为时过早。
@Andrey，为您的数据确定正确的域不是过早的优化。字段大小影响：所有 I/O、索引大小、数据存储要求、备份；对于数据的任何扫描检索，这直接转化为性能，对于查找不是直接的，但仍然会产生影响。
@Andrey，只有傻瓜才不会在设计阶段尝试优化数据库。由认为所有优化都为时过早的开发人员设计的数据库在拥有 100,000,00 条记录并且设计从一开始就是一个糟糕的选择时就很难修复。这不是过早的优化，因为这种选择会影响几乎所有的查询和性能。
@Andrey，“不会影响性能太多。” - 很棒的推理；）

标签： database-design uuid

【解决方案1】：

你把事情搞混了。

1) 代理键有两种定义

代理（1）

此定义基于 Hall、Owlett 和 Todd (1976) 给出的定义。这里的代理代表一个实体在外面的世界。代理是由系统内部生成，但仍然对用户可见或应用。

代理（2）

此定义基于 Wieringa 和 De Jonge (1991) 给出的定义。这里一个代理代表一个对象在数据库本身。代理人由系统内部生成并且对用户不可见或应用。

代理项 (1) 定义定义它在数据模型中的使用，而不是比存储模型，并用于本文。参见日期 (1998)。

（来自 wiki 在 surrogate 键上的条目；带着一点怀疑阅读这篇文章 - 例如引用“代理键比复合键更便宜（要比较的列更少）”表面上看起来很合理，但自然复合键将创建自然排序和隔离的索引，从而在浏览或分析数据时允许非常有效的扫描，这也是由于返回包含多行的结果集的相同逻辑连接实际上可以执行得更好)

无论如何，从数据模型的角度考虑代理键时，您应该不考虑您所谓的“传统”定义。

2) 您考虑 UUID 自然键的逻辑非常棘手

引用您的问题：

我会认为 UUID 更像自然键，因为它可以服务于与帐号相同的用途：to 指一个特定的帐户独特而不变的方式。

这不是自然键与代理键的定义或区别特征。自然键具有以下属性（来自wiki）：

自然键是候选键有逻辑关系该行内的属性。一个自然的密钥有时也称为域密钥。

自然键的主要优点通过代理键，它没有这样的逻辑关系，是不是已经存在;没有必要将一个新的人工列添加到架构。使用自然键（当一个可以识别）也简化了数据质量：它确保有一个键只能是一行；这 “一个版本的真相”可以是已验证，因为自然密钥是基于真实世界的观察。

通常情况下，UUID 和同一行的属性之间没有逻辑关系。但是，如果 UUID 是由外部系统分配的，并且您已经需要将它们存储为属性，那么您就有了该逻辑（类似于您可以将序列号或社会保险号视为自然键）。

只有在这个意义上，UUID 可能不再是代理键，但您仍然可能（并且可能会）为同一行的另一个候选键提供更强大和更丰富的逻辑。

【讨论】：