ツリーデータ構造のデータベース構造 [closed] 質問する

ツリーデータ構造のデータベース構造 [closed] 質問する

データベースにカスタマイズ可能なツリー データ構造 (つまり、レベル数が不明なツリー構造) を実装する最適な方法は何でしょうか?

以前にも、自分自身への外部キーを持つテーブルを使用してこれを実行したことがあります。

他にどのような実装が考えられますか? また、この実装は意味がありますか?

ベストアンサー1

最も一般的に実装されているのは、隣接リストです。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) 構造からどのような種類の情報を取得する必要がありますか。一部の構造は、構造に関する特定の種類の情報を提供することに優れています。例としては、ノードとそのすべての子の検索、ノードとそのすべての親の検索、特定の条件を満たす子ノードの数の検索などがあります。ニーズに最適な構造を決定するには、構造からどのような情報が必要かを知っておく必要があります。

おすすめ記事