MD5 哈希作为人工密钥答案

【问题标题】：MD5 hash as artificial keysMD5 哈希作为人工密钥
【发布时间】：2010-11-16 12:52:25
【问题描述】：

我看到很多应用程序使用哈希作为代理键而不是普通整数。我看不出这种设计有什么好的理由。

鉴于大多数 UUID 实现只是散列时间戳，为什么这么多数据库设计人员选择它们作为应用程序范围的代理键？

【问题讨论】：

这里回答得很好：Advantages and disadvantages of GUID / UUID database keys
0xA3 提供的链接讨论了真正的人工代理 (GUID)。我的解释是，这个线程实际上是关于使用 MD5 而不是系统生成的代理在数据库中的有意义值的散列。这是我写答案时的假设。
@dportas：您回答中的情况确实是使用哈希有意义的情况的一个很好的例子；现在我正在查看来自 SugarCRM 分支的数据库模式，并且每个表都有 UUID 样式的键，这种设计的原因让我很好奇。
@0xA3：+1，感谢您的指点。
@Paulo：是的。你的问题读起来就像你在问一般的 MD5 哈希。散列恰好用于生成 UUID 的事实与该问题不太相关。在数据库中使用哈希是一种非常有用的技术，但显然这不是您想知道的。

【解决方案1】：

哈希允许在潜在的大数据值之间进行更有效的比较 - 例如在连接中。即HASH(LargeObjectA)=HASH(LargeObjectB)的比较。例如，如果散列值是文档管理系统表中的文档，则比较散列值可能比文档更有效。

大多数 DBMS 对密钥的存储大小有限制，因此散列可能是实现更大密钥的另一种解决方法。

散列还可用于通过将数据拆分为均匀分布在数据集中的逻辑分区来优化存储。

【讨论】：

【解决方案2】：

如果应用程序的数据后端由多个分布式数据库组成，则使用递增的整数 id 可能会导致重复值。 UUID 不仅在应用程序内部而且在应用程序外部都保证是唯一的（这在加入外部数据时可能会有所帮助）。

确实，为系统中的不同数据库使用不同的 id 种子可以解决整数的唯一性问题，但管理这种方法会更加困难。

【讨论】：

【解决方案3】：

跨服务器的唯一性？在这种情况下，使用纯整数不会很好。

【讨论】：