2

レポートモデル（SQL Server Reporting Services）のデータソースを作成しています。レポートには、多くの結合と計算が必要です（たとえば、これに費やされた金額、つまり金額Aと金額Bなどの財務パラメーターの計算）...これにはすべてサブオブジェクトが含まれます。

このコードの単体テストを作成することは私にとって非常に理にかなっています（つまり、注文の収集をウォークスルーしたり、ビジネスルールやサブオブジェクトに基づいて情報を集約したりします）。このような

foreach (IOrder in Orders)
   foreach (IOrderLine in IOrder.Orderlines) 
     ...

   return ...

次に、戻り値をテストします。

ただし、このコードは、レポートビューで使用されるSQLではありません...もちろん...データベースに.NETアセンブリをプラグインできると思います。ここでの問題は、もちろん、パフォーマンスです...これらすべてのオブジェクトをC＃でループさせたくありません...遅すぎます。

したがって、当然、Linq / Lambda/Expressionツリーが私への答えのようです。ご存知のように、Linq to SQLを実行すると、式ツリーが構築され、それらに基づいて適切なSQLが生成されます。

したがって、ラムダ式を使用してLinq to Objectsでコードを記述し、サンプルコレクション（式を.netにコンパイルしたもの）でこのコードをユニットテストし、DBストアドプロシージャでLinqtoSQLと同じコードを再利用できます。 SQL Serverは、適切なSQLを生成します（Linq to SQLがすでに生成しているように）...

そうすれば、単体テストとC＃でのドメインロジックコードの記述、およびレポート用の高性能なストアドプロシージャの両方のメリットを享受できます。

可能？SQL ServerCLRストアドプロシージャでLinq/Lambdaを使用できますか？誰かがそれをしたか、それを機能させる方法を知っていますか？私は夢中ですか？あなたはそれをするより良い方法を知っていますか？

ありがとう

PS私は今、これがどのように適切に行われるべきかを理解したと思います。ウディ・ダーハンによれば、私が彼を正しく理解していれば。データベースを非正規化し、計算されたすべてのフィールドをテーブル内のオブジェクトに配置する必要があります。サブオブジェクト（OrderLineが追加された）で何かが発生すると、Customerオブジェクトはイベントを受信し、スマート値を再計算する必要があります（キャッシュして永続化します）。

次に、レポートはロジックなしで簡単に進み、高速に動作します...

4

2 に答える 2

1

いいえ、SQLCRLProcsでLINQ/Lambdaを使用することはできません。これは異なるバージョンの.NETに基づいており、これらの名前空間をサポートしていません。

于 2008-12-02T21:14:02.320 に答える
1

したがって、ラムダ式を使用してLinq to Objectsでコードを記述し、サンプルコレクション（.netにコンパイルされた式を持つ）でこのコードを単体テストし、DBストアドプロシージャでLinq to SQLと同じコードを再利用できるため、内部SQL Serverは私にとって適切なSQLを生成します（Linq to SQLがすでに行っているように）...

ストアド プロシージャから CLR コードを呼び出すことを提案するまで、この計画は問題ありませんでした。データベース プロセス自体から CLR コードを実行すると、バージョニング、構成、およびデータベースの安定性に関して多くの問題が発生します。これを行うと、問題が多すぎます。

あなたの動機は、一般的に高速なストアド プロシージャを使用する利点を得ることでした。これらのストアド プロシージャが CLR コードを実行している場合、ローカル プロセスで実行されている CLR コードよりも高速になることはありません。

LINQ で生成された式を使用すると、技術的には、ストアド プロシージャよりも多くの CPU サイクルが消費されます。これは、クエリが実行されるたびに、データベース エンジンが実行プランを再生成する必要があるためです。通常、データベース サーバーは別のマシン上にありますが、CPU バウンドではありません (代わりに、ディスクまたはネットワーク容量によって制限されます)。したがって、これは実際のパフォーマンスの問題ではありません。データベースサーバーを他のすべてのものと同じマシンで実行している場合に発生する可能性がありますが、実際の問題が発生するまで、非常に複雑なものでこれを修正しようとしないでください。

レポート生成のオーバーヘッドを減らしたい場合は、Udi の提案が適切かもしれません。ただし、最初に考慮すべき 2 つの重要な副作用があります。まず、報告されたフィールドを事前に生成する操作のパフォーマンス オーバーヘッドを増やす余裕があるか? より大きな問題は、レポート ロジックがターゲット システムを実行するコードと結び付いていることです。これにより、ビジネス コードを更新せずにレポート コードを更新することができなくなり、レポートされたコードが運用環境に置かれるとすぐにレポート コードが実行されていると見なされます。

于 2008-12-02T22:50:30.020 に答える