問題タブ [transitive-closure-table]

PostgreSQL で再帰クエリを使用して推移閉包を説明する簡単な例を作成しました。

ただし、再帰クエリには何か問題があります。私はまだ構文に慣れていないので、この要求は完全に初心者かもしれません。そのため、事前にお詫び申し上げます。クエリを実行すると、パスの結果でノード 1 が繰り返されることがわかります。誰かがSQLを微調整する方法を理解するのを手伝ってくれますか?

私はこのテーブル RC_CHAT を持っています:-

このシナリオでは、さまざまなオフィスが連絡を取り合い、議論し、決定 (GRANT/DENY) する関連するケース (それぞれのケースは REFERRAL_ID によって一意に識別されます)。CHAT_ID は、大文字と小文字に関係なく、すべての返信で一意です。オフィスは、新しいメッセージとして返信することも、以前の返信に対する返信として返信することもできます。PARENT_CHAT_ID は前者の場合は null になりますが、後者の場合は直接の親の CHAT_ID になります。

私のアプリケーションの目的は、ログイン時にオフィスが関与するすべてのケースをそのオフィスに表示することです。ここでの問題は、数百万のケースがあり、数百万の応答に乗算されることです。そのため、ユーザー アクセスと双方向性を容易にするために、エンド ユーザーの頭痛の種にならないように、すべてのケースを適切に修正できるようにケースを整理および分類する必要があります。

条件:- ある時点でのケースは、異なるオフィスの異なるタブに表示されます。

上記の例では、ケースR1は次の場所に表示されます。- KL01 の場合は「フレッシュ」。KL12、KL13は「進行中」。KL11の「処分」。

ケースR2は次のように表示されます:- KL12 の「フレッシュ」。M001、M002、KL11の「処理中」。なしの「処分」。

このように、100 万件すべてのケースを分析し、表形式でそれぞれのタブに入れます。

私が期待すること:上記の条件に従って、100 万件ほどのケースがさまざまなオフィス用に適切なタブ (新鮮、処理中、廃棄済み) に分類されて表示される必要があります。

MY QUESTION:この分析を可能にするには、どのようなテーブル構造またはクエリを使用すれば、時間とコストを最小限に抑えることができますか? ネスティング セット、Connect By...Prior など、利用可能なさまざまな手法を試してきました。しかし、私の問題に対する実現可能性についてはまだわかりません。

データベースにツリー構造があり、 、 、を使用SQLして Web ページを介して表示および編集しようとしています。JavascriptPHPMYSQL

私のニーズを満たすプラグインが見つからないようです。新しいノードをツリーに追加し、編集および削除できるようにしたいと考えています。

誰もこれについて経験がありますか？任意の推奨事項や入力は素晴らしいでしょう! ありがとう。

次のスキーマとデータがあり、クロージャー テーブル パターンを使用している場合:

+----+----------+------------+--------+ | id | ancestor | descendant | length | +----+----------+------------+--------+ | 1 | 2 | 2 | 0 | | 2 | 2 | 12 | 1 | | 3 | 2 | 13 | 1 | | 4 | 2 | 14 | 1 | | 5 | 2 | 15 | 1 | | 10 | 12 | 12 | 0 | | 11 | 13 | 13 | 0 | | 12 | 14 | 14 | 0 | | 13 | 15 | 15 | 0 | | 9 | 17 | 20 | 1 | | 8 | 17 | 19 | 1 | | 7 | 17 | 18 | 1 | | 6 | 17 | 17 | 0 | | 14 | 18 | 18 | 0 | | 15 | 19 | 19 | 0 | | 16 | 20 | 20 | 0 | +----+----------+------------+--------+

行 id のすべての兄弟行を取得するために、メイン テーブルに戻る結合クエリはどのようになります2か?

+----+----------+------------+--------+ | id | ancestor | descendant | length | +----+----------+------------+--------+ | 3 | 2 | 13 | 1 | | 4 | 2 | 14 | 1 | | 5 | 2 | 15 | 1 | +----+----------+------------+--------+

SQLでクロージャテーブル（および/または他のヘルパーテーブル）を使用して有向循環グラフを簡単にモデル化できるかどうかを判断しようとしています。たとえば、この有向グラフ (すべて下向き) があるとします。

これをクロージャーテーブルでモデル化するのに問題があります。

次の表を取得します。

• (祖先、子孫、パス長)
• (1, 1, 0)
• (2, 2, 0)
• (3, 3, 0)
• (4, 4, 0)
• (2, 4, 1)
• (3, 4, 1)
• (1、4、2)

1 と 2 の間のエッジを削除すると、クロージャ テーブルが壊れます。

最初の削除クエリは、削除してはならない 1 と 4、および 3 と 4 の間のパスを削除します。

クロージャテーブルでこれに対する解決策を見つけることができず、4 が 1 を指す場合はさらに複雑になります (周期的になります)。

この件について書かれたものはあまり見つかりませんでした。このタイプのグラフを SQL で実装する方法、または SQL がこのタイプのグラフに適していないかどうかについて、ご意見をいただければ幸いです。

エンティティ フレームワーク 6 コード ファースト アプローチを使用して、階層データ構造 (例: Product --> Product 2 ----> Product3、Product 2----> Product4) を実装したいと考えています。利用可能なアプローチはいくつかありますが、クロージャー テーブル アプローチは私のすべての要件を満たすことができるアプローチだと思います。エンティティ フレームワーク 6 でクロージャ テーブル アプローチを効率的に実装する方法や、その他の代替手段を教えてもらえますか?

ツリーに新しいノードを挿入するときに、クロージャ テーブルの深さ/長さの列を設定するにはどうすればよいですか?

先祖と子孫の値は、ツリー構造に配置されるページを表す別のテーブルの ID です。

閉鎖表:

これにより、祖先と子孫が適切に挿入されますが、深度列の挿入クエリにデータを入力する方法がわかりません。

これについて最善の方法は何ですか？本当にありがとう！

注: #postgresql の RhodiumToad の助けを借りて、回答として投稿した解決策にたどり着きました。誰かがこれを改善できる場合は、チャイムインしてください!

以前の再帰クエリ ソリューションを、複数の「ルート」(祖先のない) ノードを含む次の有向非巡回グラフに適応させることができませんでした。出力が一般にクロージャー テーブルと呼ばれるものであるクエリを作成しようとしています: 各ノードからその子孫のそれぞれおよびそれ自体へのすべてのパスを格納する多対多テーブル:

node_relation問題を特定するのは困難です。行が欠落していますか? クエリが間違っていますか？

期待される出力: