Хранение подписи SHA1 в качестве основного ключа в Postgres SQL

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

Я, очевидно, могу использовать последовательность в качестве первичного ключа и индексировать шестнадцатеричную строку SHA1 для поиска... Тем не менее, я ищу более элегантное решение, в котором я просто использую 20-байтовые значения SHA1 в качестве заданного ключа для строк, которые я собираюсь вставить/удалить/обновить в таблице базы данных. Существует ли эффективный тип хранилища, который я могу использовать для хранения, а затем использовать ключи SHA1 в качестве первичных ключей?

Мне понадобится postgres для поддержки использования 20-байтных значений в качестве ключей, чтобы это сделать.

Любой, у кого есть идеи?

Ответы

Ответ 1

Будьте осторожны с тем, что это может сделать с вашим индексом btrees. Поскольку SHA1 не будет последовательным, ваши записи будут очень медленными из-за всех прыжков в btree.

Если последовательность не будет работать, я обычно рекомендую последовательный GUID/UUID (например, например, SQL Server NEWSEQUENTIALID()).

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

Ответ 2

В частности, если вы будете делать двоичные параметры в db (например, с помощью libpq), используйте bytea. Если вы хотите сделать много манипуляций с помощью простых текстовых запросов, конвертируйте их в hext и сохраните в столбце text или varchar.

PostgreSQL, конечно, не имеет проблем вообще с 20-байтовыми ключами, кроме того, что служебные данные производительности, конечно, больше, чем с последовательностью.

Ответ 3

Вы можете преобразовать в hex или base64 и использовать столбец varchar или просто сохранить его в столбце bytea -typed. Я попробую сделать таблицы с кучей случайных значений в обоих форматах и ​​посмотреть, как они работают.

Обратитесь к к документам PostgreSQL на bytea для получения информации об этом типе.