2011-12-17 19 views
4

非常に短い背景: エンドユーザーに適切に表示される内容を制限するために、Active Directoryを使用したアクセス制御をクエリ結果に適用するCLRストアドプロシージャを使用しています。要するに、これは、ユーザーが結果にアクセスするための基準(この場合はドキュメント)を満たしていないデータテーブルから行を削除することによって行われます。CLRストアドプロシージャからT-SQLストアドプロシージャを呼び出す

このフィルタリングは、結果を表示する前にクライアントで以前に実行されていました。 SQL 2008とはるかに強力なサーバーは、このアクセスフィルタをクライアントから外す動機です。

私は、インラインのT-SQLをcomandオブジェクトに渡すのではなく、CLRストアドプロシージャから元の通常のT-SQLストアドプロシージャを呼び出すことによるパフォーマンス上のメリットがあるかどうかを確認しますこの場合、ストアドプロシージャを作成した元のT-SQLだけです)。私はどこか誰かがこれを言及している場所を見つけることができません(CLR SPの例として非常に混乱していると思われますから、おそらく:-))。 T-SQLストアドプロシージャは既に最適化されコンパイルされているので、

誰でも私のためにこれを確認できますか?

私は十分にはっきりしています。ありがとうございます。

Colm。

答えて

0

SQL CLRストアドプロシージャが特定のクエリを適切に(適切にパラメータ化されて)実行し、それをかなり頻繁に実行する場合、そのT-SQLクエリは「最適な実行計画を決定する」シーケンス全体で一度実行され、 SQL Serverのプランキャッシュに格納されます(同様のT-SQLストアドプロシージャより速く退去しません)。

このように、元のT-SQLストアドプロシージャと同じように「プリコンパイル」されます。その観点から私は何の利益も見ません。

SQL CLRプロシージャ内からSQLステートメントを微調整して、結果セットに実際にその行を含めないようにしても、最後にSQL-CLR適切にパラメータ化されたT-SQLクエリを実行するストアドプロシージャは、標準のT-SQLストアドプロシージャで、一部の行を再度除外する必要があるデータを非常に多く返すよりも、少し速いことさえあります。

+0

これは意味があります。私はSQL文も微調整します。おそらく、T-SQLクエリ自体にSIDを渡すことができます。これらのクエリは、CLR SPでのクエリの結果に対するフィルタリングに既に用意されているためです。助けてくれてありがとうMarc。 – Colm

関連する問題