MD5哈希作为人造键

-1

我看到很多应用程序使用散列作为替代键而不是普通整数。我无法看到这种设计有什么好的理由。MD5哈希作为人造键

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

2010-11-16 Paulo Scardine

很好的回答在这里：[GUID/UUID数据库键的优点和缺点]（http://stackoverflow.com/questions/45399/advantages-and-disadvantages-of-guid-uuid-database-keys） – 2010-11-16 13:11:27

由0xA3提供的链接谈论真正的人工代理（GUID）。我的解释是，这个线程实际上是关于使用MD5而不是系统生成的代理的数据库中有意义值的散列。那是我在写作答案时的假设。 – sqlvogel 2010-11-16 14:32:37

@dportas：你的回答中的情况确实是一个很好的例子，其中使用散列是有意义的;现在我正在从SugarCRM分支中查看数据库模式，每个表都有UUID样式的键，这种设计的原因令我好奇。 – 2010-11-16 16:27:30

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

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

来源

2010-11-16 13:02:38

跨服务器的唯一性？在这种情况下，使用普通整数将效果不佳。

来源

2010-11-16 13:01:56 paulbailey

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

大多数DBMS对密钥的存储大小都有限制，所以哈希可能是实现更大密钥的一种替代解决方法。

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

来源

2010-11-16 14:28:30 sqlvogel

MD5哈希作为人造键

回答

相关问题