MD5 哈希作为人工密钥
我看到很多应用程序使用哈希作为代理键而不是普通整数。我看不出这种设计有什么好的理由。
鉴于大多数 UUID 实现只是哈希时间戳，为什么这么多数据库设计者选择它们作为应用程序范围的代理键？
I'm seeing lots of applications using hashes as surrogate keys instead of plain integers. I can't see any good reason for this kind of design.
Given most UUID implementations are just hashed timestamps, why so many database designers choose them for application-wide surrogate keys?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
哈希允许在潜在的大数据值之间进行更有效的比较 - 例如在连接中。即HASH(LargeObjectA)=HASH(LargeObjectB)的比较。例如，如果散列值是文档管理系统的表中的文档，则比较散列可能比比较文档更有效。
大多数 DBMS 对键的存储大小都有限制，因此散列可能是实现更大键的一种替代解决方法。
哈希还可用于通过将数据拆分为均匀分布在数据集中的逻辑分区来优化存储。
A hash allows more efficient comparisons between potentially large data values - in joins for example. i.e. the comparison of HASH(LargeObjectA)=HASH(LargeObjectB). If the hashed values are documents in a table of a document management system for example then it may be more efficient to compare hashes than documents.
Most DBMSs have limits on the storage size of a key, so a hash may be one alternative workaround for implementing larger keys.
Hashes can also be used to optimise storage by splitting data into logical partitions that are evenly distributed across a data set.
如果应用程序的数据后端由多个分布式数据库组成，则使用递增的整数 ID 可能会导致重复值。 UUID 不仅在应用程序内部而且在应用程序外部都保证是唯一的（这在与外部数据连接时可能会有所帮助）。
确实，对系统中的不同数据库使用不同的 id 种子可以解决整数的唯一性问题，但管理这种方法会更加困难。
If the data backend for an application is made out of multiple distributed databases, using incremented integer ids might lead to duplicated values. UUIDs are guaranteed to be unique not only inside the application but outside it as well (which might be helpful when joining with external data).
It is true that using different id seeds for the different databases in the system would solve the uniqueness problem for integers, but managing such an approach would be more difficult.
跨服务器的唯一性？在这种情况下使用普通整数效果不佳。
Uniqueness across servers? Using plain integers wouldn't work well in that situation.