Генерировать уникальный идентификатор из уникального строкового ввода

Насколько уникален «уникальный»? Использование любой хорошей функции хэширования (MD5 подходит для большинства применений и легко реализуется с помощью java.security.MessageDigest.getInstance("MD5"), может привести к 128-битному числу, которое, скорее всего, будет уникальным. Использование подмножества хэш дает вам меньший идентификатор с более высокой вероятностью столкновения.

Использование поля auto_increment в БД, если оно соответствует вашему дизайну, может быть проще в реализации, действительно гарантирует уникальность и будет использовать меньшие идентификаторы, чем 16 байтов MD5. Затем вы также можете удовлетворить свое требование найти строку по ключу, чего вы не можете сделать для хэша.

Это связано с компрессией. Простейшим способом было бы побитовое упаковывание и сокращение каждого символа до минимального количества битов.

AZ - 26 символов, что меньше 32 (5 бит)

добавьте az, и это 6 бит (где-то около 12 битовых шаблонов осталось для представления других символов).

Допустим, вам этого достаточно. Таким образом, у вас есть 6x255 бит, что составляет 1530 бит для хранения вашей строки. (191 байт)

Если использовать только заглавные буквы, это немного уменьшится (до 159 байт).

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

Если вы не сможете дополнительно указать содержимое строк, вы просто не получите то, что хотите. Прости. (Если вы можете рассказать больше о содержимом строк, сделайте это. Кто-то из нас может увидеть шаблоны, которые позволят намного лучше «сжимать»)

Именно из-за отсутствия возможности делать то, что вы хотите, хэш-таблицы так круты. Они получают «в основном уникальный» номер, а затем имеют второй уровень разрешения для тестовых случаев, когда две строки хешируются до одного и того же числа.

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

У вас гораздо больше возможностей для длинной строки 255, чем для 64-битного (или любого другого) числа. Это невозможно. Добавьте поле auto_increment.

Поскольку вы используете MySQL, взгляните на CRC32.

http://www.bitbybit.dk/carsten/blog/?p=191< /а>

public String getUniqueId(String uniqueString) {
    return uniqueString;
}

Если у идентификатора нет каких-либо других ограничений, кроме «быть уникальным».

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

Если нет, вы можете запустить свои строки через GZIP или любой другой алгоритм сжатия, если вам нужно получить оригинал.

Если вам не нужно извлекать оригинал, хэш-функция, такая как MD5, — это то, что вам нужно.

Выбор правильного ключа не должен быть легким.

Вам необходимо учитывать:

• Репликация: необходимо ли совместное использование ключей между разными серверами? Если это так, вам, скорее всего, нужен какой-то уникальный хэш или guid.

• Размер таблицы/количество вставок: вы должны учитывать, что большинство rdbms хранят данные физически на жестком диске в порядке их (кластеризованного) первичного ключа. Теперь представьте, что произойдет, если вы вставите хеш-значение, начинающееся с «а», в таблицу разумного размера. Да, есть заполнение индекса, но в конечном итоге оно заполнено, и вставка одной строки может привести к перемещению пары ГБ на жестком диске.

• Нужна репликация и большие таблицы? Используйте оба. Используйте первичный кластерный автоинкрементный (длинный) целочисленный ключ и определите уникальный индекс в хеш-столбце.