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

【问题标题】：Why does the Fossil SCM use TEXT to store hashes?为什么 Fossil SCM 使用 TEXT 来存储哈希？
【发布时间】：2011-07-01 03:59:47
【问题描述】：

我想知道如何存储哈希在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 列中的字符串至少为两次，最多八次，如果值存储在使用的列中 utf8 字符集（其中每个字符使用 4 个字节）。存储字符串也会导致速度变慢因为比较大价值观和性格的需要考虑设置排序规则。

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

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

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

【问题讨论】：

标签： database-design hash fossil

【解决方案1】：

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

【讨论】：

当然它依赖于 SQLite（你认为我如何获得架构？使用 mysql fossilprj ;-)，但是我仍然不明白，假设 SHA1 存储在二进制文件中形式，数据库如何将二进制转换为十六进制摘要，反之亦然。 SQLite 具有弱类型这一事实并不能帮助我理解它是如何有效地工作的。
@Elazar Leibovich：哦，我明白你的意思了。是的，SHA1 和以纯文本形式存储（您可以使用二进制文本编辑器在存储库文件中查找 sha1sum，您会找到它）。我认为没有明显的性能损失。而且，ASCII 字符在 UTF-8 中只占 1 个字节，所以存储浪费率只有 1:2。
我认为索引器足够聪明，可以从列的限制中推断出一个好的索引。听起来是一个合理的折衷方案，调试器更简单，空间更大。

【解决方案2】：

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

【讨论】：