[解決済み] ツリーデータ構造のデータベース構造【非公開

質問

カスタマイズ可能なツリーデータ構造（レベル数が不明なツリー構造という意味）をデータベースに実装する場合、どのような方法があるでしょうか？

以前、自分自身への外部キーを持つテーブルを使って、一度やったことがあるんです。

他にどのような実装が考えられるでしょうか、また、この実装は意味があるのでしょうか？

解決方法は？

最も一般的に実装されているのは、Adjacency Listということですね。 https://blogs.msdn.microsoft.com/mvpawardprogram/2012/06/25/hierarchies-convert-adjacency-list-to-nested-sets

他にも、マテリアライズドパスやネストされたセットなどのモデルもあります。 http://communities.bmc.com/communities/docs/DOC-9902

Joe Celkoはこのテーマで本を書いており、一般的なSQLの観点から良い参考となります（上記の入れ子集合の記事のリンクで言及されています）。

また、Itzik Ben-Gannの著書 "Inside Microsoft SQL Server 2005 では、最も一般的なオプションの概要が紹介されています。T-SQL Querying"」という本があります。

モデルを選択する際の主なポイントは以下の通りです。

1) 構造変更の頻度 - 実際の木の構造がどの程度の頻度で変更されるか。モデルによっては、より優れた構造更新特性を提供するものもある。しかし、構造の変更を他のデータの変更から分離することが重要です。例えば、ある会社の組織図をモデル化することがあります。これを隣接リストとしてモデル化し、従業員IDを使用して従業員と上司をリンクさせる人もいます。これは通常、最適とは言えないアプローチです。より効果的なアプローチは、組織構造を従業員自身から切り離してモデル化し、従業員を構造の属性として維持することです。この方法では、従業員が退職したときに、組織構造自体を変更する必要はなく、退職した従業員との関連付けを変更するだけでよいのです。

2) ツリーは書き込みに強いか、読み込みに強いか - 構造によっては、構造を読み込むときは非常にうまくいきますが、構造に書き込むときに追加のオーバーヘッドが発生します。

3) 構造からどのような種類の情報を得る必要があるか - 構造によっては、構造に関する特定の種類の情報を提供することに長けているものがあります。例えば、ノードとそのすべての子を見つける、ノードとそのすべての親を見つける、ある条件を満たす子ノードの数を見つける、などです。構造体からどのような情報が必要になるかを把握して、ニーズに最も合う構造体を決定する必要があります。