「データをすべてファイル名扱いにして高速検索を実現?」記事へのコメント

安けりゃよい

[Anonymous Coward]

コンピュータ上のデータ整理をしたいと思って、見積もりを取ったら
・あるメーカーは数千万円
・HOWSは数百万
の回答があったので、同じことが出来るのであれば安いほうがよいから発注した
というのがクライアント側のアクションでは。
そして、この方法がうまくいったら数千万円コストダウンできて万歳と。

詳しい見積もりしようが分からないので何とも言えないかもしれないけど、この方法の欠点ってどこにあるのでしょう。
・Microsoftが推奨してない：でも問題なく動いてるから
・Windowsのバージョンアップ or アップデートに対応できない：そんなこと普通では
・スケーラビリティがない：普通の方法に比べて1桁安いので、仕様追加してもそんなに高くつかないだろう

Re:

[okky (2487)]

・データを見つけるのと、ファイルを見つけるのが等価になってしまっている。

に尽きるのではないかと。

1) Security 上の問題がある。
  普通なら「ファイルが open できなきゃ安全」なはずのデータが全部曝されている。何しろ、ファイル名を変更できればデータ変更は出来るわけですから。

2) PATH 名検索が死ぬほど遅いと思う。
  例えば、データ中に "fjの教祖様" が入っているレコードが欲しければ、
  "*fjの教祖様*" という PATH を探すことになるのだろう。が、
  それは結局 O(n) の検索になるんじゃないのか?

  完全一致ならば HASH とか NTFS の p

--
fjの教祖様

Re:安けりゃよい

[Stealth (5277)]

んー、どうでしょうね。

1) Security 上の問題がある。

ACL でフォルダに対して適切な制限が与えられていれば、ディレクトリリストの一覧は取れません。

ただ、OS 側がインデックス化しているためインデックスの問い合わせ権限があると情報が取れる可能性はあり。

2) PATH 名検索が死ぬほど遅いと思う。

そこは Windows Index Search が頑張るところなので。

3) Transaction 処理ができないのでは…

それは用途が違うからどうでもいいんです。

4) で、実際のところ、ファイルを open して中身を検索して close して…を繰り返すのとどっちが早いのさ??!

これって locate や find と grep のどっちが早いの? って話ですよ。