Использование ToHashCode для хранения хэша в базе данных?

Question

В настоящее время мы широко используем метод GetHashCode для хранения хэш-кодов в базе данных для отслеживания уникальных элементов. MSDN имеет ужасную запись об этом здесь

«Реализация метода GetHashCode по умолчанию не гарантирует уникальные возвращаемые значения для разных объектов. Кроме того, .NET Framework не гарантирует стандартную реализацию метода GetHashCode, а значение он будет одинаковым для разных версий .NET Framework. Следовательно, реализация этого метода по умолчанию не должна использоваться как уникальный идентификатор объекта для целей хэширования. "

Мы использовали этот подход в течение нескольких лет без проблем. Должны ли мы волноваться, и если да, то какой будет лучший подход?

Чтобы уточнить, данные поступают из внешнего источника. Мы берем от двух до трех строковых полей, добавляя их вместе в новую строку, а затем используем GetHashCode.

Answer 1

Использование хеш-кода в качестве уникального идентификатора - действительно плохая идея, потому что в конечном итоге у вас есть коллизии, если коллекция достаточно велика - и она не должна быть очень большой, статистически, вероятно, столкновение. Хэш-коды - это хороший, быстрый способ оценить, совпадают ли два объекта (при использовании одной и той же хеш-функции) - если они имеют разные значения, они совершенно разные. Однако, если они имеют хеш с одним и тем же значением, вам необходимо выполнить сравнение равенства, чтобы убедиться, что они являются одним и тем же объектом. В этот момент вам нужно сравнить свойства объекта, которые делают его уникальным, т. Е. Если эти свойства одинаковы, то объекты одинаковы.

Я бы предложил использовать уникальный индекс в базе данных о свойствах естественного ключа в сочетании с искусственным идентификатором автоинкремента в качестве первичного ключа. Тогда вы можете быть уверены, что не получаете дубликатов в БД (ограничение уникальности индекса), но вы можете быстро сравнивать объекты за пределами БД, просто сравнивая, имеют ли они один и тот же идентификатор - также гарантированно будут уникальными с помощью ограничения первичного ключа.

Answer 2

Да. Бояться. GetHashCode не может гарантировать гарантию отсутствия столкновений на любом типе, превышающем 32 бит. Учитывая, что в некоторых случаях реализация GetHashCode может быть менее совершенной (т. Е. Некоторые классы реализуют свою собственную нераспределенную версию), риск может быть выше в некоторых случаях. Несмотря на это, это плохой подход и нуждается в переосмыслении.

Я бы посоветовал немного прочитать о том, как работают таблицы хэшей, чтобы вы лучше понимали цель хеш-кода. Это действительно только эвристическая мера для быстрого хранения.

Answer 3

GetHashCode не является надежным.

У вас есть два варианта в этой связи:

1. переопределять метод GetHashCode и он возвращает Guid вместо целого.
2. Позвольте вашей БД создать уникальные значения id для вас.