Сколько цифр в 64 битах?

Всем привет, мне нужен надежный цифровой хэш для строк в БД, который будет генериться по совокупности данных из нескольких столбцов этой таблицы, что бы потом при обновлении другой таблицы проверять, если хэш изменился, значит и данные изменились, значит эту строку нужно обновит, если нет, то на нет и суда нет.
Почему именно цифровой? Компу быстрее сравнивать цифры чем буквы.
Вот тут товарищ предлагает собственный класс для генерации crc64 хэша.
Почему именно crc64? Потому что нативная php crc32() генерирует crc32-хэш, который может быть подвержен коллизиям (для разных наборов данных может быть сгенерирован один и тот же хэш), что не всегда безопасно.
Проблема вот в чем, как хранить этот crc64-хэш? И если не crc64, то может кто что подскажет? Как лучше организовать подобную проверку изменений в исходной строке?

bigint
8 байт, 64 бита.


Это свойство любых хэшей.
Коллизии будут, коллизии будут всегда. Вопрос и различие только в их количестве. Которое напрямую зависит от объёма занимаемым хэшом места.

-----
PostgreSQL DBA

Блин, какую-то фигню выдает класс автора 488c08c3e93f9c6a или 743d18d97d6497f3 - это же на bigint я так понимаю?
(Добавление)
А есть ли в природе нормальна цифровая (only digit) хэш функция максимально устойчивая к коллизиям?
(Добавление)
ЗЫ
Конечно можно конвертить это 16-ричное число в десятичное, но имхо проще уже тогда забыть про эту хрень и взять sha1 или md5

ЗЫЫ
Может когда-то в будущем, когда это начнет серьезно сказываться на производительности придется написать свою)

В школе, помнится, употреблялся термин "обратно пропорционально"

Обычные шестнадцатеричные числа...

Число из 16 шестнадцатеричных чисел, 8 байт информации и есть.


Они все бинарные.
Цифры, буквы - только отображение. Сами хэши бинарны. SHA1 - 20 байт, md5 - 16, crc64 - 8, crc32 - 4 байта (обычно их в битах измеряют, правда).
Чем больше информации в хэше - тем математически ниже вероятность коллизии. Но нулём эта вероятность не будет вплоть до размера, равного или превышающего размер исходных данных.
Ещё раз - хеши по своему определению имеют коллизии! Решайте свою задачу другим способом.

-----
PostgreSQL DBA

Угу... соглашусь с предыдущим оратором...
Если хэш не изменился, то для полной уверенности в том, что данные не изменились, надо сравнивать данные.