問題タブ [common-table-expression]

周知のとおり、CTE は SQL Server 2005 で導入され、群衆は熱狂しました。

テーブルに大量の静的データを挿入する場合があります。私が知りたいのは、次のうちどれがより高速で、他にどのような要因に注意する必要があるかです。

また

答えは、どのトリガーが存在するかなどに依存するのではないかと不快に感じていますMyTable...

(また、BULK INSERTCSV を ing したり、他の方法をいくつでも使用したりすることは、静的データを挿入するための客観的に高速で優れた方法であることを知っていて気にしません。特に、CTE と複数の挿入で注意する必要がある懸念を知りたいです。 )

私は次のステートメントを実行しています：

...エラーで終了します...

どこで間違いを犯しているのですか？

テーブルを値のカウントを含むXMLに変換する必要があります。

例えば

このような出力が必要です。これは動的である必要があるため、新しい列またはファセットを追加すると、このタイプの出力が生成されます。

これは可能ですか？

列/値が変更された場合、それを処理するソリューションが必要です。たとえば、データに応じて新しいマトリックスとファクトが生成されます。

SQL ServerのサブクエリでCTEを使用するにはどうすればよいですか？

お気に入り：

SELECT id (I want to use CTE here), name FROM table_name

I have got simple query

I am interesting in query (optimal) that only return full paths from root to leaf.

たとえば、結果の一部は

ゼロはルート 18,19 はリーフ (および子) です。 and のようなパスを部分的に無視し、完全なパス (リーフで終了) のみを取得 したいと思います0,8,12,16。0,8,12,16,170,8,12,16,17,180,8,12,16,17,19

再帰的な CTE クエリを記述しようとすると、次のエラーが発生し続けます。level, invalid column name

これはクエリです。どこが間違っていますか?

これはms sqlサーバー2005です。

SQL Server 2005 で再帰的な CTE クエリを作成しようとしていますが、奇妙な結果が得られます。私のテーブルは次のとおりです。

これは私のCTEクエリです:

わかりましたので、データセットが返されましたが、次のように繰り返しが含まれているため、期待どおりではありません。

なぜこれが起こっているのか、どうすれば修正できるのかを誰かが説明してくれたら、とても感謝しています.

私の最後の質問に関する限り、次のように各親で最初の childID を表示するには、どのように変更する必要がありますか?

そのようなテーブルがあるとしましょう（SQL SERVER 2005）

そして、このデータセットを返す CTE があります。

代わりにこの結果セットを取得できるように、最初の子 ID を保存するにはどうすればよいですか。

基本的に私がやっていることは、元の子IDを保持し、他の代わりにそれを返すことです...

これはこれまでの CTE クエリで、完全に機能します。

ここで、SQL 担当者向けの頭の体操をします。これらの関数の最初の関数が正常に実行され、2 番目の関数の実行速度が非常に遅い理由を誰か思いつきますか?

機能 A - 通常は 5 ミリ秒以内に終了します

機能 B - 実行速度が非常に遅い - 5 分後にあきらめた

この関数が何をするかを以下で説明しますが、その前に、私が知る限り、これら 2 つの関数はまったく同じであるため、重要ではないと考えていることを指摘したいと思います! 唯一の違いは、一方が CTE を使用し、他方がサブクエリを使用することです。A のサブクエリの内容と B の CTE は同一です。

誰かがこれを問題だと判断した場合: この関数の目的は、階層内の任意の数の場所のすべての可能な祖先 (親、祖父母など) を選択することです。Node列は でありhierarchyid、パスをたどるだけのdbo.GetAncestorsCLR 関数であり、データ アクセスは行いません。

UniqueIntTableこれは、1 つの列を持つユーザー定義のテーブル タイプValue int NOT NULL PRIMARY KEYです。ここでインデックスを作成する必要があるものはすべてインデックスが作成されます。関数 A の実行計画は、関数 B の場合と同様に、基本的には 2 つのインデックス シークと 1 つのハッシュ マッチだけです。

この奇妙な問題にはさらに奇妙な側面があります。

• 関数 B を使用した単純なクエリの推定実行計画を取得することさえできません。パフォーマンスの問題は、この単純に見える関数のコンパイルに関係しているようです。

• 関数 B から「本体」を取り出してインライン クエリに貼り付けると、関数 A と同じパフォーマンスで正常に実行されます。そのため、UDF 内のCTE に問題があるように見えるか、逆に、 CTE を使用する UDF。

• B を実行しようとすると、テスト マシンの 1 つのコアの CPU 使用率が 100% にまで跳ね上がります。I/O はそれほど多くないようです。

SQL Server のバグとして肩をすくめてバージョン A を使用したいのですが、ルール 1 ( 「SELECT Ain't Broken」 ) を常に念頭に置いており、関数 A からの良い結果が得られることを懸念しています。 Bが別のサーバーで行うのと同じように「失敗」するという、どういうわけかローカライズされたまぐれです。

何か案は？

更新- 再現する完全な自己完結型スクリプトを含めています。

GetAncestor 関数

スキーマの作成

上記のコード/スクリプトを使用して、CLR 関数/DB スキーマを作成できます。元のスクリプトと同じものを使用しGoodFunctionます。BadFunction

ツリー状の構造化データを表すアイテムのテーブルがあり、NULL の parent_id でマークされた最上位ノードに到達するまで、継続的に上向きにトレースしたいとします。MS SQL CTE (共通テーブル式) はどのようになりますか?

たとえば、 Benderからトップに到達するためのパスを取得する場合、次のようになります。

コメディ

フューチュラマ

ベンダー

ありがとうございます。サンプル データは次のとおりです。