为什么Fossil SCM使用TEXT来存储哈希值？

Question

我想知道如何存储哈希值 在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 docs同意我的意见

  

存储十六进制的大小惩罚   CHAR列中的字符串至少是   如果是两次，最多八次   value存储在使用的列中   utf8字符集（每个字符集   字符使用4个字节）。存储   字符串也会导致速度变慢   比较因为更大   价值观和角色的需要   设置整理规则。

这个列是不是用作键，因此它的大小不是很大？不，先生！从src/content.c@content_put:475我们可以看到

db_prepare(&s1, "SELECT rid, size FROM blob WHERE uuid=%B", &hash);

化石开发人员比我聪明，所以哈希可能以某种方式以紧凑的二进制形式存储，但我不明白究竟是怎么回事。

Answer 1

OP是对的，效率低下。然而，它有助于调试软件，并且占用的空间相对较小，因此它是开发人员方便性和效率之间的折衷。

Answer 2

Fossil根本不依赖于MySQL数据库，而是依赖于SQLite数据库。 SQLite数据库有weak typing。