0

Linq to Entities を作成し、使用しました

Enumerable.Distinct<T>(this IEnumerable<T> source, IEqualityComparer<T> comparer)

クエリで。

私の「Comparer」クラスにより、クエリはクライアント側で実行されます。期待どおりに機能し、目的の結果が得られますが、関連するテーブルに大量の行があるため、クエリが遅いため、SQL CLR を使用して Comprar クラスを含むクエリ全体をそのように実行できるかどうかを考えていました。サーバー側で。

出来ますか？

どんなアイデアでも大歓迎です。

4

2 に答える 2

2

SQL 2005 CLR は、デフォルトで .Net 2.0 フレームワークのみをサポートします。以前に.Net 3.5フレームワークをSQLサーバーにインポートしましたが、やや面倒で、いくつかのセキュリティホールが開いています（すべての詳細を思い出さないでください）が、この質問には迅速で汚いものがあります-特に

CREATE ASSEMBLY [System.Core]
AUTHORIZATION [dbo]
FROM 
'C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll'
WITH PERMISSION_SET = UNSAFE

CLR プロシージャでよく遭遇するもう 1 つの障害は、ストアド プロシージャを実行しているユーザーからのセキュリティ コンテキストが CLR プロシージャに継承されないことです。

CLR proc のデバッグはそれほど簡単ではありません。あなたはそれを行うことができますが、完全なスタック バックトレース (行番号など) を取得することはできませんでした。したがって、可能な限り CLR に移行する前にデバッグしてください。

それ以外は、CLR プロシージャで大きな問題はありませんでした。SQL 内で複雑なコードを実行することによって発生する可能性のあるパフォーマンスの問題を処理できる限り、CLR プロシージャはかなりうまく機能します。CLR プロシージャ内で大量のメモリを割り当てないでください。あなたはそれを後悔するでしょう。

追加した

私が考えたもう一つの問題。CLR proc コードの記述には、一般的なクライアント側のコードやストアド プロシージャよりも高いレベルの習熟度が必要です。これはメンテナンス上の考慮事項です。

CLR プロシージャの更新も、クライアント側のコードまたは SQL プロシージャよりも複雑になるため、これも問題になる可能性があります。これもメンテナンスを複雑にします。

CLR proc を思いとどまらせようとしているわけではありません。パフォーマンス、柔軟性、セキュリティ (更新するには DB 権限が必要です) などのメリットもあります。しかし、「CLR proc がどれほど優れていて単純であるか」について読んだときに、彼らが教えてくれない問題を文書化しようとしていました。

追加した

詳細は説明しませんが、データ バインド (行数が多い) であり、ロジックをセット ベースとして記述できる場合、TSQL のパフォーマンスはセット ベースよりもはるかに優れていることがほぼ確実です。TSQL を介して多くの計算を実行しようとすると、TSQL は遅くなります。スクリプトの実行は遅くなり、データベース I/O の実行は速くなります。TSQL はプログラミング言語としてはあまり柔軟ではないため、CLR は柔軟性と高速なコード実行を追加します。

select ステートメント (Sql 2005 以降) での APPLY の使用に慣れていない場合は、複雑なクエリを「セットベース」に保つのに非常に役立つ可能性があるため、時間をかけて理解する必要があります。回避できる場合はカーソル -- 遅くなり、データベース リソースを消費します。

于 2013-11-13T21:04:45.230 に答える
1

結果をネットワーク経由で送信する手間を省くことができるかもしれませんが、1 GB のネットワークを使用している場合は問題にならないかもしれません。特に、「大量の行」が何を意味するかについてはかなりあいまいであるためです。私たちは数十万、または数百万の話をしていますか?

どちらの場合でも、「SQL CLR を使用して Comprar クラスを含むクエリ全体をサーバー側で実行する方法で実装する」というステートメントに基づいて、SQL CLR が何をするかについて明確に理解しているかどうかはわかりません。SQL CLR でクエリを作成することはできません。.Net / CLR ストアド プロシージャと関数を作成しても、データベースとの対話用に T-SQL が置き換えられるわけではありません。これは、引き続き SELECT ステートメントを実行して結果を取得する必要があることを意味します。SQL CLR オブジェクト内で LINQ to SQL を使用すると、現在クライアントから実行されているのと同じ SQL が引き続き実行されます。

比較を行う最終目標について詳細が提供されれば、より適切な解決策を計画できる可能性があります。しかし、尋ねられた質問を考えると、このコードを SQL Server に移動しても、.Net コードで比較が行われていると仮定すると、多くのメリットが得られるかどうかは疑わしいと思われます。

編集:より明確にするために:カスタム比較子を介して比較できるようにすべての行をメモリにプルすることを回避するような方法でサーバー側で実行するようにビジネス ロジックを転送するには、SQL CLR 関数を作成して使用する必要があります。 WHERE 句で。そのため、コレクションですべてを使用できるようにするのではなく、基本的に一度に 1 行ずつ比較のために関数に送信するようにモデルを変更します。

于 2013-11-13T21:43:11.613 に答える