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