ツリーデータ構造のデータベース構造


151

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

自分自身への外部キーを持つテーブルを使用する前に、これを1回実行しました。

他にどのような実装を見ることができますか?この実装は意味がありますか?



SQL Server(2008以降)は、hierarchyidデータ型を
BornToCode

回答:


80

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


こんにちは、私は質問に記載されているこのまったく同じ問題に直面しています。上記のトピックについて質問したいと思います。ナンバー1トピック(同じテーブルで参照されるParentIdを持つ組織化されたテーブル(従業員ではなく組織化されたテーブル))のような構造を考えると、特定の領域のボスをだれが設定する必要があります。その特定の領域のすべての従業員を直接それに割り当てます。その特定の地域のボスをどこに配置しますか?同じエリア内ですか、それとも上のグループですか?私のアプローチは、彼/彼女を上記のグループに参照させることです。ありがとう。
Marcos Buarque、

1
最初のリンクが壊れているようです。
ホルヘレイタオ2013年

すばらしい答えです。ありがとう@JeremyDWill!
bobocopy 14

56

MySQLでの階層データの管理をご覧ください。リレーショナルデータベースに階層(ツリー状)データを格納および管理するための2つのアプローチについて説明します。

最初のアプローチは、隣接リストモデルです。これは、本質的には、テーブル自体を参照する外部キーを持つことです。このアプローチは単純ですが、ツリー全体の構築など、特定のクエリでは非常に非効率的です。

この記事で説明する2番目のアプローチは、ネストされたセットモデルです。このアプローチは、はるかに効率的で柔軟です。詳細な説明とクエリ例については、記事を参照してください。


あなたのリンクは議論されている非常に興味深いトピックを持っています。ありがとう!
フリッツ

9

Relational DataBaseを使用してツリーデータ構造を整理する必要がある場合、Postgresqlには、階層的なツリーのような構造に格納されたデータのラベルを表すデータ型を提供するクールなltreeモジュールがあります。そこからアイデアを得ることができます(詳細については、http//www.postgresql.org/docs/9.0/static/ltree.htmlを参照してください)。

通常、LDAPはレコードを階層構造で編成するために使用されます。


2

それ自体への外部キーを持つテーブルを持つことは、私には理にかなっています。

次に、SQLの共通テーブル式またはOracleの前のステートメントによる接続を使用して、ツリーを構築できます。


LogID ID列を持つログテーブルと、LogID列を指すFKを持つParentLogID列があります。トランザクションの最初のログ行が書き込まれると、SCOPE_IDENTITY()を取得します。他のすべてのログレコードは、ParentLogID列にこの値が書き込まれます。これは、一緒に属する行をグループ化するのに非常に役立ちます。これは、何が起こったかを確認するための唯一の実際の方法です。これがないと、複数のトランザクションからのログ行がすべて混ざり合った巨大な混乱になります。
和基。

@KM-彼は「理にかなっている」ではなく「理にかなっている」と言った
John Rasch



弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.