問題タブ [transitive-closure-table]

私はこのようなテーブルを持っています

子IDを5とすると、親IDは1（出力）になります。

子IDを9とすると、親IDは7になります。（出力）

つまり、ルートの親IDは0であり、クエリはそこで停止する必要があります。

そのようなクエリを解決する方法は？

助けてください。

階層型データベース構造（列IDなどPARENT_ID）があり、行ごとに定義されており、最上位の行には。がありNULL PARENT_IDます。

このテーブルのすべての関係を別のテーブルにフラット化します。たとえば、祖父母、親、孫の1つの階層に3つのレコードがある場合、3つのレコードがあります。

(grandparent, grandchild)階層クエリを実行して孫が祖父母の子孫であると判断するのではなく、このフラット化されたテーブルにレコードが存在するかどうかを簡単に確認できます。

私の質問は、このフラット化されたテーブルを使用して、2つのノード間にあるすべてのレコードを最も効率的に返すにはどうすればよいかということです。例を使用して、パラメーターとして、grandparentおよびをパラメーターとして使用して、レコードgrandchildを取得するにはどうすればよいですか。(grandparent, parent)

これを解決するために階層クエリを使用したくありません...結合なしでこれを実行できるかどうか疑問に思っています。

SQL Serverで、直接の親子関係だけを持つ別のテーブルからクロージャーテーブルを生成するために使用しているコードがいくつかあります。これに対して非常に単純なクエリを実行して、系統を決定できます。今、私はmySQLでこれらすべてを行う必要がありますが、クロージャテーブルを生成するための再帰クエリで問題が発生しています...

私の元のSQLサーバークエリは

私の最初の問題は@@ROWCOUNTの置換を見つけることです...しかし、おそらく再帰クエリはmySQLでは完全に異なりますか？ビル・カーウィンのプレゼンテーションもチェックしました

PS。「COLLATEDATABASE_DEFAULT」は、パフォーマンスの問題のために必要なものでした。

ありがとう。

ツリーを表す履歴推移閉包表があります。

サンプルデータは次のとおりです。

残念ながら、ルート ノードを見つけるための現在のクエリでは、完全なテーブル スキャンが発生します。

表面的にはそれほど高価には見えませんが、100 万行に近づくにつれて、この特定のクエリは厄介になり始めています... 特に、レガシー サポートのために隣接ツリーを取得するビューの一部である場合はそうです。

推移閉包のルート ノードを見つけるより良い方法はありますか? 古いレガシ コードをすべて書き直したいのですが、できません...そのため、何らかの方法で隣接リストを作成する必要があります。ルート ノード以外のすべてを取得するのは簡単ですが、より良い方法はありますか? 私はこの問題について間違った方法で考えていますか?

80 万行のテーブルに対するクエリ プラン。

隣接リスト方式を使用してレコードを関連付けるテーブル (テーブルA ) と、クロージャ テーブルを使用して同じレコードを関連付ける別のテーブル(テーブルB ) があります。どちらも同じグラフをキャプチャするため、両方を同期させる必要があります。

問題は、閉鎖テーブルを更新する最良の方法は何ですか?

私が見ているように、3つの選択肢があります：

1. トリガー。A のINSERT/UPDATE/DELETE で、新しいクロージャを計算する sproc を実行します。 短所: Aへの変更は、長い同期 (ロック?) 操作になります。デッドロック (?) の可能性があります。
2. アプリケーション コード。A の変更を Add/Update/Delete メソッド (リポジトリ パターンなど) に絞り込み、新しいクロージャを計算する sproc の呼び出しでそれらをオーバーロードします。 短所: DB への余分な往復。別のスレッドが同時に逆の方法でAまたはBを変更すると、整合性の問題が発生する可能性があります。たとえば、別のアプリケーションがBではなくAを変更することを決定した場合、整合性の問題が発生する可能性があります。
3. バックグラウンド アップデーター。Aへの更新を継続的に検索し、対応する更新をクロージャー テーブルに行う 2 次プロセスを作成します。 短所:複雑 (追加サービスの作成と管理)。同期なしのウィンドウ。

「最良の」オプションがない場合でも、トレードオフについての考えは非常に高く評価されます!

私たちのオンライン ショップ (PHP/MySQL) では、Bill Karwin によって説明されているように、カテゴリ構造に推移閉包テーブル (祖先、子孫、長さ) を使用しています。

非常に柔軟で便利だと思いますが、再帰なしで完全なカテゴリ ツリーを出力する方法がわかりません。これは可能ですか？

たとえば、次のような出力が必要です。

• オーディオ
  • ポータブル
    • MP3
• コンピューティング
  • 光学ドライブ
    • DVD-RW
  • 入力デバイス
    • 無線
      • キーボード
• 家庭用器具
• テレビ
  • 液晶
    • ワイドスクリーン
  • ブラウン管

必要に応じて、カテゴリの深さの合計によって制限します。

これはこのモデルの制限ですか、それとも回避する方法はありますか? 現在、再帰を使用して結果をキャッシュしています。

SQL を介して階層をモデル化する方法として、クロージャー テーブルについて読んでいます。

[SQLAlchemy] には、クロージャ テーブルを使用してオブジェクト インスタンスの階層コレクション (ツリー構造のコレクション) を作成およびトラバースするためのサポートが組み込まれていますか?

現在のUSERテーブル：

現在のUSER_RELATIONSテーブル:(2つの外部キー-祖先->USER.id-子孫->USER.idがあります）

現在のTRANSACTIONSテーブル:(1つの外部キー-chid->USER.idがあります）

すべてのリレーションは正しく設定されており、ユーザーが自分を参照している別のユーザーの参照に参加して入力すると作成され、階層ツリーが作成されます。

以前、私はこの設定を正しく取得しようとしていて、クロージャーテーブルの方向に私を向けた「PugganSe」からいくつかの大きな助けを得ました。

現在、単一の元のリファラー（祖先）とそのすべてのリファラーユーザー（子孫）のツリー全体を見ることができます。また、事前定義された数の子孫を参照した各ユーザーを平準化する自動平準化システムをセットアップしました。

これでショップが追加されました。各ユーザーに参考のために少しお返しをしたり、他のユーザーを招待して買い物をしたりしたいと思います。「ささいなこと」は、基本的に、ツリー構造に基づく売上の割合です。

説明：

質問：誰かにMySQLクエリを確認して、正しく実行しているかどうかを教えてもらいたいです。子孫ステータス<祖先ステータスである祖先ツリー内のすべての子孫によるトランザクションの合計と支出の合計額を取得したいと思います。誰か助けてもらえますか？現在、relations.length / status =ごとに4回実行しています。これは、最高値である4より下に4つのステータスレベルがあるためです。

クエリ：

これで、t2.statusが増加して祖先のステータスと等しくならず、t1.lengthが1に減少するたびに、length=0が祖先自身であるためです。

私の仮定と方法は正しいですか、それともこれを行うためのより簡単な方法がありますか？

I have am using a closure table for some page heirarchy. I want to be able to delete a page and update the level of the children it leaves.

Prior to deleting page 3 I've attempted to update the levels and then deleteing reocrds for page 3 the goal of such being:

describing this with a (invalid) suquery like so:

which obviously fails on the update.

Ideally would like to complete in one query but if tmp able is way to go then so be it - performace on this is more important that sweet sql sweetness...

MySQL と PHP のスレッド コメント システムを開発しています。Closure Table パターンを選択しましたが、問題があります。ツリー全体を取得するには、クエリ (クエリ) が必要です。どうやってするか？これについて多くのことを検索しましたが、最適なものが見つかりません。スレッド化されたコメントに適したものがあれば、お知らせください。お返事ありがとうございます。