него я буду делать хеш-строку или uuid, будут ли проблемы с коллизиями?
Думаю, что если хранить не очищенную строку (ибо она может быть очень длинной), а uuid от неё
что такое uuid от строки? uuid это просто идентификатор, генерируемый некоторым определенным способом. в частности uuid3 использует хеш-суммму.
Ога. теоретически коллизии возможны для любых хэшей и ююидов, потому что это представление фиксированной длины исходной строки любой длины Хотел уточнить, стоит ли делать хеширование, если да, то какое
задача то у всего этого какая?
Хочу сравнивать, был ли уже такой текст
размер поля uuid полностью совпадает с размером хэша MD5
Да, хочу чтобы хеш поддерживал уникальных вариаций более 60млн, если GUID вариант возьму, будет нормально?
только содержимое не совпадает, т.к. UUID кодирует еще и номер версии в определенных битах.
длина UUID и MD5-хэша — 128 бит, т.е. 2^128 вариантов. нет смысла заморачиваться, просто в SQL делать что-то типа: UPDATE ... SET uuid_field = '8BADF00D...' а значение получать из стандартной функции md5_file() я так делал контроль повторов для картинок и файлов. замечательно работает
Вы заблуждаетесь. В UUID3\5 из исходного MD5\SHA-1 хеша используются только 121 бит.
A UUID is written as a sequence of lower-case hexadecimal digits, in several groups separated by hyphens, specifically a group of 8 digits followed by three groups of 4 digits followed by a group of 12 digits, for a total of 32 digits representing the 128 bits.
как это связано с тезисом, на который вы отвечаете?
мне же не важно как там генерируются UUID-ы. я просто использую стандартный тип данных, размером в 128 бит. без него была б альтернатива только разбивать значения на несколько бигинтов
Если криптографический хэш (из несломанных) — то не будут.
Обсуждают сегодня