Database design 为什么化石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）位。我也发现我的观点与我一致

存储十六进制的大小惩罚 CHAR列中的字符串至少为 两次，如果 值存储在使用 utf8字符集（其中 字符使用4个字节）。存储 字符串也会导致速度变慢 因为比较大 价值观和塑造个性的需要 将排序规则考虑在内

是不是因为这个列没有被用作键，所以它的大小也没什么大不了的？不，先生！从中我们可以看到

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

---

化石开发人员比我聪明，因此哈希可能以紧凑的二进制形式存储，但我不明白这到底是怎么回事。

化石根本不依赖MySQL数据库，而是依赖SQLite数据库。SQLite数据库有。

操作正确，效率低下。但是，它有助于调试软件，占用的空间相对较小，因此它是开发人员方便性和效率之间的折衷方案。

当然它依赖于SQLite（你认为我是如何获得模式的？使用

mysql fossilprj

；-），但是我仍然没有得到，假设

SHA1

以二进制形式存储，数据库如何将二进制文件转换为十六进制摘要，反之亦然。SQLite有弱类型这一事实并不能帮助我理解它是如何高效工作的。@Elazar Leibovich:哦，我明白你的意思了。是的，SHA1总和以纯文本形式存储（您可以使用二进制文本编辑器查找存储库文件中的SHA1总和，您会找到它）。我认为没有明显的表现惩罚。此外，ASCII字符在UTF-8中只占用1个字节，因此存储浪费率只有1:2。我认为索引器足够聪明，可以从对列的限制中推断出一个好的索引。听起来是一个合理的折衷方案，更简单的调试器可以获得更多的空间。