07/03/14 23:53:07 y4c2ZpRt
ハッシュを使っているのは文字列の代わりに固定サイズの短い数字を使った方が
B木のキー(の一部)として優秀なだけだと思います。ただハッシュなので、B木を
降りていった後にハッシュの元の文字列かどうかは確認する必要があり、B木の
キーで同じ値になっている部分を走査したり探索したりする必要があるのかなぁ
と思いました。
元の文字列に対してハッシュ値が現実的に十分1:1になっている(一意になって
いる)なら最後に走査したり探索したりする必要はないんだけど、B木まで使う
(レコード数が大きいことを想定している)ファイルシステム(手堅い印象)で
ハッシュが重ならないことを前提にしたりするの？と疑問が残ったので、資料と
ソースを探してみました。で、>>57 というわけ。
でも、仮に調べたことが想定通りだったとしても、取得側のロジックで単に同一
ハッシュを線形探索しているということまでしか突き止めていないので、挿入側
のロジックでエラーとしていないかどうかまでは確認できていません。ただ、
取得時に線形探索までしておいて、挿入時に同一ハッシュをエラーにするのも
あれだし、ハッシュも絶対一意とするには短いような気がしたので載せちゃい
ました。
最後に、、こう思うという意見を言っただけで>>35 に回答を求めているわけ
ではないので、間違い指摘は歓迎ですが、煽ったりしないでね。適当に流して
くれて構いません。(長くてゴメン)