使用ToHashCode在数据库中存储哈希？

Question

我们目前正在广泛使用GetHashCode方法将哈希码存储在数据库中以跟踪唯一项。 MSDN在这里有一个可怕的条目

“GetHashCode方法的默认实现不保证不同对象的唯一返回值。此外，.NET Framework不保证GetHashCode方法的默认实现，并且它返回的值在不同版本之间是相同的因此，不得将此方法的默认实现用作散列目的的唯一对象标识符。“

我们几年来一直使用这种方法没有问题。我们应该担心，如果是这样，那会是一个更好的方法吗？

详细说明，数据来自外部来源。我们将两到三个字符串字段，将它们一起添加到一个新字符串中，然后使用GetHashCode。

Answer 1

是。害怕。 GetHashCode无法在任何大于32位的类型上提供无冲突保证。鉴于在某些情况下，GetHashCode的实现可能不够完美（即某些类实现了自己的错误分布版本），在某些情况下风险可能更高。无论如何，这是一种糟糕的方法，需要重新思考。

我建议稍微阅读哈希表的工作原理，以便更好地理解哈希码的用途。它实际上只是一种快速存储的启发式措施。

Answer 2

使用哈希码作为唯一标识符是一个非常糟糕的主意，因为如果集合足够大，最终会保证会发生冲突 - 并且在统计上可能存在之前不必非常大有碰撞。散列码是一种很好的，快速的方法来评估两个对象是否相同（假设相同的散列函数） - 如果它们散列到不同的值，它们肯定是不同的。但是，如果它们散列为相同的值，则需要进行相等比较以确保它们是同一个对象。此时，您需要比较使其唯一的对象的属性，即，如果这些属性相同，则对象是相同的。

我建议在数据库中使用自然键属性中的唯一索引以及人工自动增量id作为主键。然后你可以确定你没有在DB中获得重复插入（索引的唯一性约束），但是你可以通过简单地比较它们是否具有相同的id来快速比较DB之外的对象 - 也保证是唯一的通过主键约束。

Answer 3

GetHashCode不可靠。

在这方面你有两个选择：

1. 覆盖GetHashCode方法 并让它返回一个Guid而不是 整数。
2. 让您的数据库创建 您的唯一ID值。