問題タブ [transitive-closure-table]

ツリーを構築するために「クロージャテーブル」を使用して階層データベースを構築しています。これは自己参照テーブルであり、2 つのキーが主キーになる必要があります。

問題は、3 つだけを期待しているときに、5 つの列になってしまうことです。

これが私が試したものです：

結果は、5 つの列を持つテーブルです。

1. タスク ID
2. 子ID
3. 長さ
4. Child_TaskId
5. Child_ChildId

私は期待しました：

1. タスク ID
2. 子ID
3. 長さ

流暢な API が欠落していると推測していますが、それ以外の場合は作業できませんでした。

隣接リスト モデルを使用して格納されたカテゴリの階層を含むデータベースがあります。

階層は 3 レベルの深さ (架空のルート ノードを含まない) で、約 1700 のノードが含まれています。2 番目と 3 番目のレベルのノードは、複数の親を持つことができます。次のように、追加のテーブルが多対多の関係に使用されます。

(データの整合性などのために) 推移的クロージャ テーブル メソッドの使用に移行した場合、クロージャ テーブルの値を生成する実行可能な比較的簡単なクエリはありますか? (SQL Server 2005 を使用)

Bill Karwin のModels for hierarchy dataなどの記事やプレゼンテーションを調べましたが、単一のノードに対する挿入クエリしかなく、そのようなツリーを作成するには永遠に時間がかかります。

ありがとう。

編集:
CategoryHierarchy テーブルの RelID は純粋に主キーのためのものであり、Category テーブルのノード ID には関係ありません。

また、クロージャーテーブルとは、次のようなテーブルを意味します。

最初の 2 つの列は複合主キーであり、Category.id に対する個別の外部キーです。

MySQL にいくつかの階層データを保存しています。さまざまな理由から、(ネストされたセットや隣接リストなどの代わりに) クロージャ テーブルを使用することにしました。これまでのところうまく機能していますが、現在、このツリーを HTML で実際に表示する方法 (つまり、正しいインデントを使用) を理解しようとしています。

例として、私がそのような木を持っているとしましょう...

• 食べ物
  • 果物
    • りんご
    • 洋ナシ
  • 野菜
    • 人参

私の「Foods」テーブルは次のようになります...

私の「閉鎖」テーブルは次のようになります...

今、理想的にはこのように、これをHTMLで正しく表示するにはどうすればよいのだろうかと思っています...

...これは、質問の冒頭にあるように、ツリーを箇条書きで表示します。とにかく、どんな助けでも大歓迎です！

チャールズ

グラフの推移閉包を計算しようとしています。このグラフを例として考えてみましょう（写真はグラフ、その隣接行列、および接続性マトリックスを示しています）。

このページで見つけたWarshallのアルゴリズムを使用して、この接続マトリックス（=推移閉包？）を生成します。これは、図のものとは異なります。

また、このアプレットを使用してみましたが、これも別の結果になります。

ですから、どの行列が正しいかわからないので、今は少し混乱しています。誰かが私の問題に光を当てることができますか？

http://www.slideshare.net/billkarwin/models-for-hierarchical-dataの「クロージャ テーブル」セクションで説明されているように、コンテンツ ノードを 2 つのテーブルに格納するカスタム CMS 実装があり、この gem https:// Ruby on Rails 3 および MySQL の下のgithub.com/mceachen/closure_tree 。

コンテンツ ツリーの変更 (ノードの編集、挿入、移動、削除など) がルート ノード (パブリケーション) の新しいバージョンを作成するバージョン履歴を実装する時が来ました。また、ユーザーは古いバージョンを見て、元に戻すことができます。元に戻すアクションは、元に戻したバージョンのコピーである新しいバージョンを作成します。

これを達成するためのよく知られた方法はありますか？または、この種のアイデアや実装例を誰かが持っていますか?

任意の入力をいただければ幸いです。

クロージャ テーブルとして格納された階層データ構造の並べ替えに関する問題を解決する方法を教えてください。

この構造を使用して、Web サイトのメニューを保存したいと考えていました。すべて正常に動作しますが、問題は、正確なサブツリーをカスタム順序でソートする方法がわからないことです。現時点では、アイテムがデータベースに追加された順序でツリーがソートされます。

私の構造は、Closure Tables に関するBill Karwin の記事やその他の投稿に基づいています。

以下は、いくつかの DEMO データを含む私の MySQL データベース構造です。

1 つのツリーに対する SELECT クエリは次のとおりです。

クエリが取得する __ROOT_ = 1 の DEMO インスタンスの場合:

しかし、たとえば、Cat 1.1 と Cat 1.2 の順序を変更する必要がある場合はどうすればよいでしょうか (名前またはカスタム オーダーに従って)。

ブレッドクラムのソリューション (ブレッドクラムでソートする方法) を見たことがありますが、それらを生成および変更する方法がわかりません。

組織階層の推移閉包を表すテーブルがあります（つまり、単一のルートを持つツリー）。

各ユーザーがアクセスを許可されている組織を含む別のテーブルがあります。

システムは、ユーザーがアクセスできる各組織に関連付けられた支出のロールアップをユーザーに表示します。私はいつでも、ユーザーに会社のビュー（つまり、ルート）を表示して、ユーザーに直接の子組織のリストと、彼の組織が合計にどれだけ貢献しているかを表示することから始めることができます。ほとんどの場合、子は1人であり、ユーザーは複数の子を表示する前に複数のレベルをドリルダウンする必要があります。私は、複数の子供を示す最初の組織（つまり、LCA）からプレゼンテーションを開始したいと思います。

特定のユーザーの場合、ルートへのパスのセットを簡単に見つけることができますが、最も一般的でない祖先を見つけるのに問題があります。私はpostgresql9.1を使用していますが、データベースに依存しないソリューションを好みます。最悪の場合、ルートへのパスをアプリケーションのコードに戻し、そこでLCAを計算できます。

と呼ばれる隣接リストテーブルがあります（これには、再帰を容易にするためにマップされattributeたクロージャテーブルもあります）。attribute_closure

テーブル内の各エントリは 4 つの階層型の 1 つであり、各型は親型のエントリattributeを継承およびオーバーライドできます。考えられる 4 つのタイプは、階層によって、category、product_line、product、modelです。したがってcategory、定義された属性のツリーがあり、これは継承され、product_lineいつでもオーバーライドできます。productmodel

これは既存のアプリケーションの既存の構造であるため、再構築の提案は使用できません:-)

したがって、隣接リストattributeには次の列がid, parent_id, overrides_idありますoverrides_id: が設定されている場合、オーバーライドされた属性の の値と常に一致します。attribute.idparent_idoverrides_idparent_idparent_id

階層タイプごとに、タイプを属性にマッピングするサポート テーブルがありますcategory_id, attribute_id。

すべてのオーバーライドを考慮して、完全な属性ツリーを取得できる必要があります。

データの例 (この特定の例は製品レベルに限定されていますが、アイデアは理解できます)。必要に応じて、独自のサンプル データでさらに肉付けしてください。

attribute

category_attribute

product_line_attribute

product_attribute

上記の属性を含むツリーを30955照会すると、属性 ID のみが返されるはずです。表示されている他の 2 つの属性は 30955 までに廃止されるはずです。

前述のように、 、 、 をマップする典型的なクロージャ テーブルもancestorありdescendantますlevel。クロージャーを使用してオーバーライドが有効になったツリーを返す結果を含めることができる場合は、追加のブラウニー ポイント。:-)

階層構造で共通の属性を持つモデルのセットを同時に操作するためにclosure_treeを使用するときに、データベースのデッドロックを回避するにはどうすればよいですか？

それらは次のフレーバーで存在します：

発行する場合#append/prepend_sibling

クロージャーテーブルを再構築する場合

with_advisory_lockは有望に見えます。何かご意見は？

クロージャ テーブルを使用して、階層ツリーとして編成されたデータをモデル化しようとしています。ツリー内のノードを表すエントリは特別なものではなく、次のように定義されています。

ノード間のパスは、次のクロージャー テーブルを使用して定義されます。これは、祖先ノードへの FK、子孫ノードへの FK、および祖先と子孫の間のパスの長さ (つまり、ノードの数) で構成されます。

Regionすべての行とそれぞれの親ノード (つまり、RegionPath.PathLength = 1 の場所)を取得するにはどうすればよいでしょうか。私の SQL は少しさびていますが、SQL クエリは次のようになるはずです。

Django の QuerySet API を使用してこれを表現するための助けをいただければ幸いです。