0

ハッシュをどのように保存すればよいのか疑問に思いました。FossilSCMでは、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のドキュメントが私に同意することもわかりました

16進文字列をCHAR列に格納する場合のサイズのペナルティは、少なくとも2倍、値がutf8文字セット（各文字が4バイトを使用する）を使用する列に格納されている場合は最大8倍です。文字列を保存すると、値が大きくなり、文字セットの照合規則を考慮する必要があるため、比較が遅くなります。

この列はキーとして使用されていないので、そのサイズはそれほど重要ではありませんか？いいえ！からsrc/content.c@content_put:475見ることができます

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

化石開発者は私より賢いので、ハッシュはおそらくどういうわけかコンパクトなバイナリ形式で保存されていますが、それがどれほど正確に起こっているのかわかりません。

4

2 に答える 2

1

OPは正しいです、それは非効率的です。ただし、ソフトウェアのデバッグに役立ち、必要なスペースも比較的少ないため、開発者の利便性と効率の妥協点になります。

于 2011-02-21T13:35:33.820 に答える
0

FossilはMySQLデータベースにまったく依存していませんが、SQLiteデータベースに依存しています。SQLiteデータベースには弱い型付けがあります。

于 2011-02-21T09:49:02.920 に答える