Мне было интересно, как хранить хеш
В Fossil SCM хэши SHA1 хранятся как текст длиной 40.
CREATE TABLE blob(
rid INTEGER PRIMARY KEY,
rcvid INTEGER,
size INTEGER,
uuid TEXT UNIQUE NOT NULL,
content BLOB,
CHECK( length(uuid)==40 AND rid>0 )
);
sqlite> select * from blob;
1|1|169|6fc9d28454d4d070ca863bbbdbf9835f3505d585|
2|2|687|f59c73c1dbdea48cd2330d5a309445d756fc6901|
3|2|221|84ddeef14a657366246e6d9dcb11e2b3669cd896|
4|3|695|0311113ca8c18fb3e83c9e35e0e49e373c089f08|
5|3|224|5c577d268419caea733544ba5c81932beead3bf7|
Для такого непрофессионала, как я, кажется неэффективным, что каждому персонажу нужно 8 бит и он дает 4 (0-f). Я также обнаружил, что MySQL документы , чтобы согласиться со мной
Размер штрафа за хранение гекса
строка в столбце CHAR не менее
два раза, до восьми раз, если
значение хранится в столбце, который использует
набор символов utf8 (где каждый
символ использует 4 байта). Хранение
Строка также приводит к замедлению
сравнения из-за большего
ценности и необходимость принять характер
установить правила сопоставления.
Это тот столбец, который не используется в качестве ключа, и, следовательно, его размер не такой уж большой вопрос? Нет, сэр! С src/content.c@content_put:475 мы можем видеть
db_prepare(&s1, "SELECT rid, size FROM blob WHERE uuid=%B", &hash);
Разработчик окаменелостей умнее меня, поэтому хэш, вероятно, каким-то образом хранится в компактной двоичной форме, однако я не понимаю, как именно это происходит.