MD5 хэш как искусственные ключи

Question

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

Учитывая, что большинство реализаций UUID являются просто хэшированными временными метками, почему так много дизайнеров баз данных выбирают их для суррогатных ключей для всего приложения?

Answer 1

Если бэкэнд данных для приложения сделан из нескольких распределенных баз данных, использование увеличенных целочисленных идентификаторов может привести к дублированным значениям. Uuids гарантированно будет уникальным не только внутри приложения, но и вне его (что может быть полезно при соединении с внешними данными).

Это правда, что использование разных семян идентификаторов для различных баз данных в системе решит проблему уникальности для целых чисел, но управление таким подходом будет сложнее.

Answer 2

Хэш обеспечивает более эффективное сравнение между потенциально большими значениями данных - например, в соединениях. т.е. сравнение хэша (bigobjecta) = хэш (bigobjectb). Если хешированные значения являются документами в таблице системы управления документами, например, то может быть более эффективным сравнить хэши, чем документы.

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

Хэши также можно использовать для оптимизации хранения путем разделения данных на логические разделы, которые равномерно распределены по набору данных.

Answer 3

Уникальность на серверах? Использование простых целых чисел не будет хорошо работать в этой ситуации.