Web 上には、SQL Server 2005 の CLR 統合を使用して Web サービスを使用する方法を説明するチュートリアルがいくつかあります。ほとんどの場合、プロセスはかなり複雑に見えます。データベースの信頼レベルを変更する必要があることや、sgen ツールを使用して静的な XmlSerializer アセンブリを作成することなど、いくつかの問題に遭遇しました。そして、私はまだそれを正しく機能させていません... (私はそれにもう少し時間とエネルギーを注ぐ必要があると確信しています)
このタイプのアーキテクチャに移行する場合、セキュリティ、パフォーマンス、およびメンテナンスにどのような影響がありますか? これはおそらくかなり頻繁に使用されるプロセスであり、メンテナンスの容易さは比較的重要です。
これを UDF として SQL Server に統合するか、コンソール/Web アプリケーション用のスタンドアロン .NET ライブラリにするかを自由に選択できます。SQL CLR と外部アセンブリとの統合は、問題を起こす価値がありますか?
あなたは自分の質問に答えたと思います。個人的には、WebService を呼び出すものは、SQL Server の外に存在するのに適していると思います。複雑さ、信頼レベルの上昇、そしてあなたが言及したように全体的な複雑なプロセスにより、ソリューションの文書化と維持が困難になります。
簡単に言えば、いいえ、SQL CLR 統合はおそらく問題に値しないということです。
より長い答えには、データベースでの CLR のプログラミングから始まるいくつかのポイントがあります。正しく使用すれば優れたツールですが、正しく使用しないとメモリ消費量が増加し、パフォーマンスの問題が発生する可能性があります。RegEx機能の追加など、非常に特殊な機能のためにデータベースで使用していますが、できるだけ多くの問題が発生するのを防ぐために十分にテストされたコードで控えめに使用されています.
2 つ目は、ご指摘のとおり、セキュリティを変更する必要があり、潜在的なリスクが生じることです。
スタンドアロン アプリケーションを使用して、データをサーバーにロードします。あなたはより多くのコントロールを持ち、リスクを減らし、より簡単に時間を過ごすことができます.
Exchange と AD の両方で Web サービスを呼び出す clr 手順を実行しており、上記の投稿に同意します。それは機能しますが、SQL Server 内の CLR でメモリが特別な方法で処理されるため、すぐにメモリ不足の問題に遭遇しました。ご想像のとおり、小さなクエリのパフォーマンスは問題ありませんが、まったくスケーリングしません。
一般に、データベースのパフォーマンスがアプリケーションのパフォーマンスを決定します。そのようなロジックをデータベースに配置することは、自分が行っていることを完全に制御できない場合はノーだと思います。
外部リソースに依存しない単純なテキスト操作やその他の計算には、CLR を使用します。