2013年5月7日火曜日

SQLアンチパターン読書会 「ナイーブツリー」 に参加してきました #sqlap

SQLアンチパターン読書会 「ナイーブツリー」
http://sqlap.doorkeeper.jp/events/3682

はじめに

前回のレポートはこちら→SQLアンチパターン読書会 「ジェイウォーク」 に参加してきました #sqlap
今回は、「ナイーブツリー」ということで自分自身経験した内容が話せればいいなと思い、参加いたしました。
ツリー構造に馴染み深い掲示板に関する事を自己紹介と併せて話しましたが、ニフティサーブから近年のSNSまで幅広く、世代というものを実感しました。


ディスカッション



アンチパターンを使っても良いとして上げられたCTE(共通テーブル式)が使えるDBであれば、シンプルでテーブルも少なくて済むということでした。
今回の解決策として上げられた3つのパターンについてですが、経路列挙モデルの場合、DBによっては型が用意されていたりして人間にも扱いやすいのですが、デメリットとして前回のジェイウォークに当てはまってしまうので、アプリケーション側で制約を守るようにしなければならないことです。
次に入れ子集合モデルでは、データの変更より参照が多い場合に使われることが多く、ORMによってはプラグイン等でサポートしているものもあるそうです。
デメリットとしては、ツリー構造の欠損等が発生した場合、人間で修正するのがとても難しいということです。
閉包テーブルモデルでは、入れ子集合と同様に変更より参照が多い場合に利用する場合が多く、2つテーブルを利用することがメリットでありデメリットでもあるということでした。
ツリー構造のスケールによってどのモデルを採用するかを検証し、コストに見合ったものを選ぶのが望ましいのではないかと思いました。

私の場合、組織階層を表現する方法として経路列挙モデルを採用しました。対象となる組織の階層も深くなく、横の広がりもそれほど大きいものでは無かったためです。
経路列挙のデメリットとしてはジェイウォークと同様にインデックスが使えないことです。ですが組織の数そのものが少ないため、デメリットがそれほど目立ちません。
もし今後階層がもっと深くなったり、横に広がるような場合は、残りのモデルやCTEを検討する必要が出てくるかもしれません。


今回のツリー構造をRDBMSでどのようにしたらよいのかについて、@t_wadaさんからJOE CELKO氏が書かれた本を紹介して頂きました。
1冊まるごとツリー構造について書かれた本らしいので、もう少し巨大なツリー構造に立ち向かう前に読んでみたいと思いました。


同じくJOE CELKO氏が書かれた本として上記の本があるそうなので、こちらの本も取り寄せたいと思います。


入れ子集合の監訳注にあった入れ子区間モデルは、ここが参考になると思います。

おわりに

次回の「IDリクワイアド」は、ORMとの関係でいろいろと物議を醸した章なので、楽しみです。

主催の@natstu_nananaさん、参加者の皆様、会場を提供してくださった株式会社アルティネット様ありがとうございました。
次回もまたよろしくお願いします。
投稿者 時刻:
このエントリーをはてなブックマークに追加
ラベル: ,