我们需要将UUID添加到大多数对象和数据库表中。
除了序列生成的代理键之外，您是否将UUID用作代理键，或者更确切地说是自然键，即使用私有代理键并另外添加列/属性来保存UUID？
我看到它经常直接用作代理/主键。不知怎的，我不喜欢这个主意。
有人可能会将UUID视为自然键，因为它应该是一个具有全局含义的唯一标识符，就像任何其他自然键一样，独立于系统的特定实现，即如果您将数据移动到另一个在系统中，UUID必须保持不变，而根据定义，代理键没有真正和持久的含义。
也许我应该澄清更多：假设我们有一个帐户表。传统上会有一些内部代理密钥和一个由帐号组成的自然密钥（在帐户报表上打印等）。
而UUID不是＆＃34;可读＆＃34;作为帐号，我会将UUID视为更自然的密钥，因为它可以起到与帐号相同的目的：以独特且不变的方式引用特定帐户。 （传统）代理密钥永远不会出现在系统之外，因为它完全是私有的，可以随时更改，不需要外部引用。
从这个意义上说，UUID不是典型的代理键（？）。
答案 0 :(得分：3)
你把事情搞混了。
1）代理键有两种定义
代理（1）
该定义基于Hall，Owlett和Todd（1976）给出的定义。 这里代理人代表一个实体 在外面的世界。代理人是 由系统内部生成但是 尽管如此，用户仍然可以看到 应用。
代理（2）
该定义基于Wieringa和De Jonge（1991）给出的定义。 这里代理人代表一个对象 在数据库本身。代理人 由系统内部生成 并且对用户不可见或 应用
代理（1）定义定义 它在数据模型中的用法 比存储模型和使用 本文。见日期（1998年）。
（来自wiki在surrogate键上的条目;阅读文章时有点怀疑 - 比如引用'代理键加入的成本较低（要比较的列数较少）而不是复合键'表面看起来似乎合理，但是自然复合键将创建自然排序和隔离的索引，允许在浏览或分析数据时进行非常有效的扫描，同样由于返回包含多行的结果集的逻辑连接实际上可以执行好多了）
无论如何，当从数据模型的角度考虑代理键时，你应该不考虑你所谓的“传统”定义。
2）你考虑UUIDs自然键的逻辑是非常滑的
引用你的问题：
我会更喜欢UUID 自然关键，因为它可以服务于 与帐号相同的目的：到 指的是一个特定的帐户 独特而不变的方式。
这不是自然键与代理键的定义或区别特征。自然键具有以下属性（来自wiki）：
自然键是候选键 与...有逻辑关系 该行中的属性。很自然 key有时被称为域密钥。
自然键的主要优点 在代理密钥上，没有代理密钥 这种逻辑关系就是这样 已经存在;没有必要 添加一个新的人工柱到 架构。使用自然键（当一个 可以识别）也简化 数据质量：确保存在 键只能是一行;这个 “一个版本的真相”可以 验证，因为自然的关键是 基于现实世界的观察。
通常，UUID与同一行的属性之间没有逻辑关系。但是，如果UUID由外部系统分配，并且您已经要求将它们存储为属性，则您具有该逻辑（类似于您可以将序列号或社会安全号视为自然键）。
只有在这种意义上，UUID可能会停止使用surogate键，但仍然可能（并且可能会有）更强大且更丰富的逻辑用于同一行的另一个候选键。