このエントリでは関係データベースにおける木構造の表現について説明してきましたが、実は一般的な業務システムにおいて木構造が必要になる場面はそれほど多くありません。 その理由としては、現実世界におけるモノゴトの分類はきれいな木構造に収まらないものが多いということが挙げられます。 物販系のシステムなどでは商品カテゴリが木構造として登録されることがありますが、例えば、
- 「書籍」(下位分類として「文庫」「雑誌」など)
- 「音楽」(下位分類として「CD」「楽器」など)
のような分類を設定したとして、「ヴァイオリンの弾き方指南書」はどちらに入れるべきでしょうか? もちろん、その本には ISBN が割り当てられているでしょうから「書籍」に入れるべきではありますが、「音楽」での検索結果にも出てきてほしいところ。 このような場合、階層構造を作らず、多対多で柔軟な関連付けができるタグ付け (tagging) を採用した方が、管理者・利用者双方にとって使い勝手の良いシステムになることが多いようです。
また、企業や自治体などの組織系統が木構造としてモデル化されることもありますが、そのような場合には大抵、ノード数は100未満、階層の深さはせいぜい 5 といったところに落ち着きます。 そのような小さなデータセットに対しては、テーブルの内容すべてを一気に読み込んでしまい、メモリ上で木構造を構築する方が面倒がなく取り回しも良くなります。