このーきなんのき

気になる木

 皆さん、「実用性については正直よく分からないけど気になる・・・」という印象のようですね。この気になる木が実用性に関してクリアしなければならない課題は、木の更新SQLをなるべく簡素化することと、パフォーマンスを向上させることです。

 私は、前者に関してはあまり心配していません。更新SQLをプロシージャにしてライブラリ化しておけば使いまわせるようになりますから、そういうのが出回れば、サイトで説明しているアルゴリズムを知らない人たちでも広く利用できるようになるでしょう。

 パフォーマンスに関しては、関与するファクターが多くて一概に判断できない、というのが正直な感想です。これからのメモリやハードの性能やDBエンジンの技術動向にもよります。ただ、セルコもこの点には当然、無関心ではなく、第5章「Frequent Insertion Trees」は、頻繁に更新が起こる木をどうやって効率よく扱うか、という問題のためにまるまる一章が割かれています。要点としては「あらかじめ余裕を持って、大きな円を隙間を空けて配置しておく。添え字が連番でなくても気にしない」ということです。そうすれば、更新と無関係なノードの座標には影響は及ばない。問題は、どの程度の余裕をどうやって持たせるか、さらに余裕がなくなったときにどうやって余裕を広げるか、というあたりの方法を体系化することですが・・・このあたりは追ってまとめます。

 この入れ子集合モデルを使った実例があると参考になっていいんだけどな、と思って今探しているんですが、あんまり見つからないですねえ。私が知る限り、CakePHPACLテーブル群と、あとはMovableTypeもこのモデルを使っていると小耳に挟んだことがありますが・・・。

 このモデルを全面的に採用してアプリケーションを作る、「我こそは」という勇猛果敢なベンチャー企業はおられないでしょうか? ここは一つ、全世界のDBエンジニアのために火中の栗を拾っていただきたい。骨は私が拾いましょう。

 ん? 私?




 かもめーはかもめー
 ひとりで海をーゆくのがーお似合いー