問題タブ [cross-apply]

次のテーブル構造があります。

SubIdが null で、RawLineNumberが 1 ずつ昇順であり、SeqNumberが 1 ずつ昇順であるすべての行にSubIdを更新したいだけです。

RawLineNumber 2 と 3のSubId を A100 に、 RawLineNumber 11のSubIdを A200 に、RawLineNumber 26 と 27 の SubId を A300に
更新したいと考えています。

仕事をするカーソルがありますが、それを処理するために CTE を使用できますか?

情報のリストを含むテーブルを使用CROSS APPLYして正規化するにはどうすればよいですか?FOR XML

以下のように正規化する必要があります

でできると思いますCROSS APPLY FOR XML。それを行う他の方法はありますか？

SQL Server 2005の更新ステートメントのfrom部分でcrossapply句を使用することは可能ですか？

MS SQL Server が を処理する方法に問題があることがわかりましたCROSS APPLY。

私が使用しているデータベースには、次のスキーマの価格設定システムがあります。

サービス -> 価格モデル <- 価格コンポーネント ( 「->」はテーブルを指す外部キーを示します)

一部の価格モデルには「段階的価格設定」があります。つまり、金額パラメーターがさまざまなしきい値に達すると、価格が上昇します (1 ～ 3 単位は価格 A、4 ～ 8 単位は価格 B など)。

私が抱えている問題は、INNER JOIN[Price Model ID] の [Service] と [Price Component] の間で重複行が生成されることです。これは、Price Component の価格を実際に使用していないため、表の別のフィールドにすぎないためです。 [Price Component] 行の各行で同じです。

この問題の論理的な修正は、これを行う を に置き換えることINNER JOINですCROSS APPLY。

問題は、この変更とは一見関係のない他のいくつかの結合で効率が完全に破壊されていることです。実行計画を見ると、以前は 2.3 サイクルかかっていた結合に 480 万サイクルかかっています。

元のクエリに a を追加しようとしましたDISTINCT([Price Component] テーブルからの一意のデータを使用しないため、実行時間が 4 倍になることを除いて、これは関数ソリューションです。必要な値だけを返そうとしました。 [価格コンポーネント] テーブルから、しかしそれはあまり役に立たないようです:

奇妙なことに、CROSS APPLYを anに変更するOUTER APPLYと、他の結合の問題は修正されますが、CROSS APPLY の目的が無効になります (これは、基本的に anINNER JOINと anの違いであると理解していOUTER JOINます)。

での複雑さの異常な増加を引き起こしている可能性があるものについて、誰か考えや洞察を持っていCROSS APPLYますか?

アップデート

したがって、実行計画の解釈方法についてさらに読んだ後、次のことを学びました。

• 元のクエリ ( INNER JOINs を使用) は、与えられたフィルター データで始まる長い一連の入れ子になったループです。フィルターがインデックス付きフィールドにある限り、応答時間はかなり迅速です。

• 変更されたクエリ (を使用CROSS APPLY) は、より長い一連のハッシュ マッチであり、指定したすべてのテーブル (フィルターを除く) を結合し、最後にフィルターを適用します。常に死よりも遅い。

• 変更されたクエリ (を使用OUTER APPLY) を使用すると、元のクエリと同じことを実行できますが、WHERE 句と一致しない結果は除外されません。オリジナルと同じくらいきびきび。

CROSS APPLY問題は、要求されたフィルターの前にすべてのテーブルを結合するように計画を変更するのはなぜですか?

アカウント (表)

ペイアウト (表)

アカウントテーブルとペイアウトテーブルがあります。ペイアウトテーブルは海外からのものであるため、私たちはそれを制御することはできません. これにより、レコード ID フィールドに基づいて 2 つのテーブルを結合できないという問題が残ります。これは、解決できない問題の 1 つです。したがって、Account#、SupplierID (2 列目と 3 列目) に基づいて結合します。これにより、（おそらく）多対多の関係が作成されるという問題が発生します。ただし、レコードがアクティブである場合はレコードをフィルター処理し、支払いが作成されたときに支払いテーブルで 2 番目のフィルターを使用します。支払いは毎月作成されます。私の見解では、これには2つの問題があります

1. クエリが完了するまでにかなりの時間がかかります (非効率的である可能性があります)
2. 削除されるべきではない特定の重複が削除されます。例は、配当表のレコード 6 と 8 です。ここで起こったことは、顧客を獲得した後、顧客がキャンセルした後、彼が戻ってきたということです。この場合、+50、-50、+50 です。ここでも、すべての値が有効であり、監査目的でレポートに表示する必要があります。現在、+50 は 1 つだけ表示されており、もう 1 つは失われています。たまに来るレポートには他にもいくつかの問題があります。

これがクエリです。groups by を使用して重複を削除します。レポートの月に出現する限り、PayOut テーブルのレコードが重複しないことを考慮した、優れた事前クエリが必要です。

これが現在のクエリです

このクエリは最適ですか? CROSS APPLY または WHERE EXIST を使用して改善することはできますか?

このクエリは、担当者の支払いを取得するために使用されることに注意してください。したがって、すべてのレコードには、割り当て先の repid フィールドがあります。理想的には、Select WHERE Exist クエリを使用したいと思います。

次の SQL Server 2008 クエリがあります。

これは基本的に のEすべてのレコードの最終値を取得しますTが、 のレコードがTの最初のレコードの前にある場合Eは、 の最初のレコードを取得しEます。

MySQLで同等のものは何ですか?

編集

ここに私のスキーマとデータがあります:

SQLフィドル:

私の希望する出力:

SELECTステートメントの「現在の」ノードからxsi：type属性を読み取りたいと思います。私のXMLは次のようになります。

私のselectステートメントは次のようになります。

私の問題は、LineItemTypeという行がエラーをスローすることです。XQuery構文'@{http://www.w3.org/2001/XMLSchema-instance}:type'はサポートされていません

CROSS APPLYを使用しない場合、単一のタイプを読み取ることができるため、奇妙です。

2番目のステートメントはSQLServer2005で機能します。相互適用を使用するときにxsi：type属性を読み取る可能性はありますか？

助けてくれてありがとう

次のようなクエリがあります。

まったく同じ式を何度も繰り返さないようにするため: (CASE WHEN ... THEN ... ELSE ... END)CTE を定義し、select、where、および group by 式を使用してそのようなテーブルをクエリしたかったCalculatedValue

残念ながら、これは機能しませんgroup by。CTE

何度も繰り返さないようにするために使用できる他の方法はありますCASE WHEN...か？

CROSS APPLYは JOIN のようなものです。また、EXISTS でも JOIN を実行できると思います(相関サブクエリ)

混乱しています。CROSS APPLY と EXISTS の使用の違いは何ですか?

EXISTS に対して CROSS APPLY を実行する必要があるのはいつですか?

T-SQL ではCROSS APPLY、ステートメントの左右のテーブル間で考えられるすべてのバリエーションを取得するために使用できます。今、私は次のような状況にC#あり、LINQ-to-Objects を使用して問題を解決する方法があることを願っています。

TestDataオブジェクトに似たオブジェクト（以下のような）のリストがありKeyValuePair<string, object>ます（ちょうどaKeyとValueプロパティ）：キーはすべてにすることができ、同じキーを持つ複数のオブジェクトが存在する可能性があります。

リクエストされたキーのリストもあります：

ここで、リスト内のキー間の KeyValuePair オブジェクトのすべての可能な組み合わせを取得したいと考えていますrequestedKeys。

LINQ-to-Objects を使用して私の問題を解決することは可能ですか? そうでない場合は、とにかくそれを構築する最も効率的な方法を教えてください.

編集1:
結果がどうあるべきかをより明確にするために:
次のようなLINQ-to-Objectsクエリが必要です:
@ジョアンナは、複数のsに関するヒントに感謝しますfromが、問題は次のとおりです:この構文では、動的なsの量from。私の場合、リストfrom内のアイテムと同じ数の sが必要ですrequestedKeys