使用 uuid 作为主键和/或代理键？
我们需要将 UUID 添加到大多数对象和数据库表中。
您是否会使用 UUID 作为代理键，或者除了序列生成的代理键之外还作为自然键，即使用私有代理键并另外添加列/属性来保存 UUID？
我发现它经常直接用作代理/主键。不知怎的，我不喜欢这个主意。
人们可能将 UUID 视为自然键，因为它应该是一个具有全局含义的唯一标识符，就像任何其他自然键一样，独立于系统的特定实现，即如果您将数据移动到另一个系统， UUID 必须保持不变，而代理键根据定义没有真正且持久的含义。
也许我应该澄清更多：假设我们有一个帐户表。传统上，会有一些内部代理键和一个由帐号组成的自然键（如打印在账户报表等上）。
尽管 UUID 不像帐号那样“可读”，但我认为 UUID 更像是自然密钥，因为它可以起到与帐号相同的作用：以唯一且不变的方式引用特定帐户。 （传统）代理键永远不会出现在系统外部，因为它是完全私有的并且可以随时更改，因此它不能存在任何外部引用。
从这个意义上说，UUID 不是典型的代理键（？）。
We are required to add UUID's to most of our objects and database tables.
Would you use the UUID as surrogate key, or rather as natural key in addition to a sequence generated surrogate key, i.e. use a private surrogate key and in addition add a column/attribute to hold the UUID?
I see that it is often used directly as surrogate / primary key. Somehow I don't like the idea.
One might view a UUID as a natural key, since it should be a unique identifier with a global meaning just like any other natural key, independent of a particular implementation of a system, i.e. if you would ever move your data to another system, the UUID must stay the same, whereas surrogate keys by definition have no real and lasting meaning.
Maybe I should have clarified more: suppose we have an Account table. Traditionally there would be some internal surrogate key and a natural key consisting of the account number (as printed on account statements etc.).
Whereas the UUID is not as "readable" as the account number, I would view a UUID more like the natural key because it could serve the same purpose as the account number: to refer to a particular account in a unique and unchanging manner. The (traditional) surrogate key never appears outside of the system, since it is completely private and could be changed at any time, no external references must ever exist to it.
In that sense a UUID is not a typical surrogate key (?).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你把事情搞混了一点。
1）代理键有两种定义
（来自 wiki 上关于 代理 键的条目；带着一点怀疑的态度阅读这篇文章 - 例如引用 ' 代理键比复合键的连接成本更低（需要比较的列更少）'表面上看起来似乎很合理，但自然复合键将创建自然排序和隔离的索引，从而实现非常高效的扫描当浏览或分析数据时，也由于返回包含多行的结果集的相同逻辑连接实际上可以执行得更好）
无论如何，当从数据模型的角度考虑代理键时，您不应该考虑您所说的“传统”定义。
2）您考虑 UUID 自然键的逻辑非常狡猾，
引用您的问题：
这不是自然键与代理键的定义或区别特征。自然键具有以下属性（来自 wiki）：
通常，UUID 和同一行的属性之间没有逻辑关系。但是，如果 UUID 是由外部系统分配的，并且您已经需要将它们存储为属性，那么您就拥有该逻辑（类似于您可以将序列号或社会保险号视为自然键）。
仅在这个意义上，UUID 可能不再是代理键，但您仍然可能（并且可能会有）同一行的另一个候选键具有更强大和更丰富的逻辑。
You are mixing things up a bit.
1) There are two definitions of surrogate keys
(from wiki's entry on surrogate keys; read the article with a bit of scepticism - for example quote 'Surrogate keys are less expensive to join (fewer columns to compare) than compound keys' might seem reasonable on the surface, but natural compound keys will create indexes that are naturally ordered and segregated, allowing for very efficient scans when browsing or analyzing data, also due to the same logic joins that return resultsets containing several rows can actually perform much better)
Anyway, when considering surrogate keys from the perspective of the data model, you should not consider what you call a 'traditional' definition.
2) Your logic for considering UUIDs natural keys is very slippery
quoting from your question:
This is not a defining nor distinguishing characteristic of natural keys vs surrogate keys. Natural keys have following properties (from wiki):
Normally there is no logical relationship between UUID and the attributes of the same row. However, if UUIDs are assigned by an external system and if you already have a requirement to store them as an attribute then you have that logic (similarly like you could consider a serial number or social security number a natural key).
Only in this sense UUID might stop being surogate key and yet still you might have (and probably will have) stronger and richer logic for another candidate key for the same row.