0

以下に定義するように、ツリーテーブルからデータを抽出する方法を探しています。

テーブルツリーの定義：
-TreeID uniqueidentifier
TreeParent uniqueidentifier
TreeCode varchar（50）
TreeDesc varchar（100）

一部のデータ（23k行）、親参照をテーブルのIDに戻す

次のSQLは、ツリー全体をレンダリングします（約2分30分かかります）

私は次のことをする必要があります。

1）各ツリーノードをそのLVL 1親で
レンダリングします。2）「SomeText％」のようなTreeDescと一致する説明を持つすべてのノードをレンダリングします
。3）単一のツリーID用のすべての親ノードをレンダリングします。

アイテム2と3は2分30かかるので、これはもっと速くする必要があります！
項目1は、SQLを強制終了したり、永久に使用したりせずに、それを実行する方法を理解できません。

どんな推測も役に立ちます

ありがとう

ジュリアン

WITH TreeCTE(TreeCode, TreeDesc, depth, TreeParent, TreeID)
AS
(
  -- anchor member
  SELECT cast('' as varchar(50)) as TreeCode , 
   cast('Trees'  as varchar(100)) as TreeDesc, 
   cast('0' as Integer) as depth, 
   cast('00000000-0000-0000-0000-000000000000' as uniqueidentifier) as TreeParent, 
   cast('00000000-0000-0000-0000-000000000000' as uniqueidentifier) as TreeID

  UNION ALL

  -- recursive member
  SELECT s.TreeCode, 
   s.TreeDesc, 
   cte.depth+1, 
   isnull(s.TreeParent, cast('00000000-0000-0000-0000-000000000000' as uniqueidentifier)), 
   isnull(s.TreeID, cast('00000000-0000-0000-0000-000000000000' as uniqueidentifier)) 
  FROM pdTrees AS S
    JOIN TreeCTE AS cte
      ON isnull(s.TreeParent, cast('00000000-0000-0000-0000-000000000000' as uniqueidentifier)) = isnull( cte.TreeID , cast('00000000-0000-0000-0000-000000000000' as uniqueidentifier))
)

-- outer query

SELECT
s.TreeID, s.TreeCode, s.TreeDesc, s.depth, s.TreeParent    
FROM TreeCTE s
4

2 に答える 2

0

HIerarchyID データ型を見てください。これはまさにそのために行われます。

それに加えて、あなたの再帰はそれとうまくやっていくための最悪の方法です。場合によっては、必要に応じてデータを一時テーブルに集約することで、手順を踏む必要があります。または - 忘れてください。真剣に-プログラムの開始時にツリー構造を作成するべきではありませんが、必要に応じて23.000個のアイテムをロードする必要はありません。

それはまだ言われています-2:30分も長すぎます。メモリ内で計算されるもの用。テーブルに適切なインデックスがあると確信していますか? 確認できるように、上記のクエリのクエリ プランを公開していただけますか? 多くのテーブル スキャンを強制する SQL 設計の問題に遭遇したようです。

于 2010-04-15T09:51:01.010 に答える
0

ありがとう、主な問題は、データがすでに存在し、長い間行われてきたことです

ボスがメインの親 (つまり、ルート + 1) を画面に表示するときに各項目に表示するように要求するまで問題はありませんでした。ツリー モードの場合は、オンデマンドでノードをロードするので問題ありません。選択された noes (つまり 90+) とそのメインの親。

現在、「大学院開発者」の 1 人は一時テーブルを使用し、適切なテーブルが見つかるまで paent によってテーブルの親をスキャンして戻しました。これにはノードあたり 30 秒ほどかかりました。

テーブルを再設定せずにこの情報を取得し、変更スクリプトをすべてのクライアントに展開するより良い方法を考えようとしています。

さらに悪いことに、ajax でファイル化されたルックアップを実行するときにメインの親を表示する必要がないため、1 秒未満で非常に高速にする必要があります。入力時にフィルタリングします。

テーブルを再設計する必要があるようです:(

また、8.5m を超える行を含む GeoPlantData でも同じ問題が発生すると思います!!!!

情報をありがとう

ジュリアン

于 2010-04-15T12:50:13.397 に答える