問題タブ [cross-apply]

次のようなテーブルがあります。

レコードを次のように分割したい：

SQL サーバーのみを使用してこれを行うにはどうすればよいですか?

ありがとう、

-

CROSS APPLY が使用されているため、このビューのインデックスを作成できないことは確かです。誰でもこれに対する回避策を提案できますか? 大量の XML データを処理する場合、インデックスが作成されていないこのようなビューの操作は非常に遅くなります。

編集：

XML 自体にインデックスを付ける方法はありますか?

エイリアス化された式ごとに個別の CROSS APPLY を使用するか、可能であれば同じ CROSS APPLY で複数の式を定義する必要がありますか?

コードで生成される多くの非常に複雑な SQL クエリ (多くの場合、12 の JOIN を含む 4 ～ 5 ページの長さ) をリファクタリングしています。一部のパーツはさまざまな状況で再利用されるため、多くの場合、クエリは 5 つか 6 つの深さでネストされます。クエリをネストする一般的な理由は、1 つのクエリがいくつかの値を抽出し、計算を実行し、その値にエイリアスを割り当てるためです。次に、囲んでいるクエリは、エイリアス値などを使用してさらに計算を行います。これが必要なのは、エイリアス化された式は、それを定義するクエリの他の場所では参照できず、外側のクエリでのみ参照できるためです。(コードにも存在する別の方法は、同じ長い部分式をクエリ全体で数十回繰り返すことです。)

このスパゲッティ SQL を簡素化するために、CROSS APPLY を使用してこれらのテレスコープ クエリを折りたたみ始めました。CROSS APPLY を使用すると、エイリアスを割り当てて、同じクエリ内の別の場所で使用できます。CROSS APPLY 句のいずれも、副選択を介して新しいテーブルを導入したり、UDF を呼び出したりしないことに注意してください。

最初は、同じ CROSS APPLY に多くの式を入れました。ただし、私のコードはモジュール化する必要があります。ユーザーはフィルター用にフィールドを選択でき、さまざまな列に対して同様の統計を生成するため、さまざまな状況でさまざまなフィールドが必要になります。したがって、互いに少しだけ異なる多くの同様のクエリが作成されます。一部のフィールドは他のフィールドの上に構築され、一部はクエリで以前に定義された特定の JOIN に依存しているため、すべてを同じ CROSS APPLY に入れることはできません。したがって、CROSS APPLY の数は異なる場合があります。

さらに、抽出された一部のフィールドは、新しいエイリアスによって隠蔽され、再定義されます (通常、NULL を削除したり、デフォルトを指定したりするため)。したがって、CROSS APPLY で定義されたフィールドが他の場所で参照される場合、CROSS APPLY のテーブル エイリアスを指定する必要があります。あいまいさを取り除きます。

これの結論は、CROSS APPLY に論理的な名前を付ける必要があり、パフォーマンスに関心があるということです。CROSS APPLY の数が変更された場合、CROSS APPLY が単純なカウンター (computed1、computed2 など) で番号付けされている場合、特定のフィールドの名前参照がcomputer3.[FIELD NAME] からcomputer4.[FIELD] に変更される場合があります。 NAME] は、クエリの残りの部分全体に波及効果をもたらします。これは、異なる C# プロシージャへの呼び出しによって組み立てられた可能性があります。これはメンテナンスの問題です。

私が検討している代替案は、計算された各式を個別の CROSS APPLY に配置することです。CROSS APPLY の名前は、式のエイリアスから派生します。例えば：

1 つの CROSS APPLY を使用する:

4 つの CROSS APPLY を使用する:

この複数の CROSS APPLY アプローチを使用すると、新しい適用を追加したり削除したりしても変更されない名前を簡単に生成でき、フィールドを参照するコードでテーブル エイリアスがどうなるかを予測できます。ただし、これはより多くの CROSS APPLY ステートメントを意味します。パフォーマンスへの影響は何ですか? CROSS APPLY またはその他の SQL Server 機能を使用して、これを行うためのより良い方法はありますか? (クロスデータベースである必要はないので、Microsoft のみの機能で問題ありません。)

MS SQL Server 2005 用に記述された SQL クエリを Postgres 9.1 に移行する必要があります。このクエリで
代用する最良の方法は何ですか?CROSS APPLY

GetCitizenRecModified()function はテーブル値関数です。この関数のコードを配置することはできません。なぜなら、この関数は非常に巨大で、計算が難しく、放棄できないからです。

クロスアプライを使用してテーブルからフィールド「tagtext」を取得し、各タグテキストを別のテーブルのTagsという新しいフィールドのエントリとしてまとめるストアドプロシージャがあります。ただし、クロスアプライがどのように機能するかについては気にせず、エラーが発生しているようです：無効なオブジェクトmyArticles。

私のspからの関連コードは次のとおりです。

次に、spを使用しているWebサービスは次のとおりです。

私はテーブルを持っています（以下のスクリプト）：

国ごとにグループ化した都市を選択します。2つのアプローチを使用してクエリを実行できます。

以下の「applyquery」と同じ結果を返すことができる「crossapply」のないクエリはどこにありますか？：

クエリ：

うまくいかない

ステートメントの詳細を含むxmlドキュメントがあります。

これは、ステートメント固有の詳細に対して正常に機能します。

ただし、シングルトンが必要であり、最初の値のみを返します。最初の値だけでなく、請求書のすべての値が必要なので、シングルトンは機能しません。

次のようなクロスアプライステートメントを使用して情報を取得できます。

これにより、ステートメントの各請求書からID、日付、および金額が返されます-完璧です。

すべての請求書の詳細を抽出しようとすると、問題が発生します。現在、7つの相互適用ステートメントがあり、次のメッセージが表示されます。

「クエリプロセッサが内部リソースを使い果たし、クエリプランを作成できませんでした。これはまれなイベントであり、非常に複雑なクエリ、または非常に多くのテーブルやパーティションを参照するクエリでのみ発生します。クエリを簡略化してください。このメッセージを誤って受け取った場合は、カスタマーサポートサービスに詳細をお問い合わせください。」

私がやりたいのは、請求書に1つのクロスを適用し、selectステートメントの正確なフィールドを絞り込むことですが、「。」を使用しない限り、ステートメントがシングルトンを返すようにする必要がありますが、必要なすべてのデータを取得できません。

selectステートメント内で名前空間を指定することについていくつかの調査を行いましたが、すべての例で名前空間がxmlドキュメントのノードではなくhttpアドレスに設定されており、このアプローチを使用してまだ何も返されていません。

私が探している結果は次のようなものですが、請求書の詳細がさらに含まれています。

ここからどこへ行けばいいの？

編集：私はいくつかの不要な情報を削除しました。ここでの私の目標は、請求書固有の詳細をすべて取得することです。

次のようなSQLクエリを実行しています

結果は、最初の85行で問題なく表示され、86番目以降のUDFから派生した列では常にNULLになります。where句またはorderby句を追加して結果セットを変更すると、結果の完全なセットを返すのは常に最初の85行です。85という数字は一貫しているので、見落としているものだと思います。

誰もが提供できるどんな助けも素晴らしいでしょう

出力として複数の行を与えるテーブル値関数があり、出力として2列があります。

今、従業員テーブルのすべての従業員のクエリでこの関数を使用したい

CROSS APPLY を使用していますが、時間がかかり、結果が得られません。

これは私が試したクエリです

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

他のテーブルに含まれていない RecordsID 行を削除する必要があります。テーブル TableOne、TableTwo、TableThree の 1 つが空である場合があり、その場合はレコードを削除しないでください。

結果表は次のようになります。

空のテーブルのため、INNER JOIN を使用できません。関数でこれらのコードを使用しているため、レコードを持つテーブルのみを含む動的 SQL ステートメントを作成して実行することはできません。

私は IF ステートメントでこれを行うことができましたが、私の実際の状況では、チェックするケースが多く、結合するテーブルが多く、結果として多くのコードの重複が発生しています。

そのため、CROSS APPLY を使用して、これをより賢く、よりクリーンにする方法はないかと考え始めました。