0

ユーザー定義ストアド プロシージャの代わりに拡張ストアド プロシージャを使用する場合 拡張ストアド プロシージャと clr ストアド プロシージャの利点は何ですか

4

4 に答える 4

0

たとえば、csv エクスポート、pgp 暗号化、http または soap 呼び出しを追加します。基本的に、外部アプリケーションを使用するのではなく、内部でより多くのビジネス プロセス要件を実行できるように、SQL サーバーを拡張します。

于 2017-01-01T18:43:23.523 に答える
0

拡張ストアド プロシージャを使用すると、C などのプログラミング言語で独自の外部ルーチンを作成できます。

基本的に、非SQLのもの。明らかに、通常のストアド プロシージャはすべて SQL に関するものです。

MSDNの次の点に注意してください。

この機能は、Microsoft SQL Server の将来のバージョンでは削除される予定です。新しい開発作業でこの機能を使用することは避け、現在この機能を使用しているアプリケーションを変更することを計画してください。代わりに CLR 統合を使用してください。

だからそうあるべきだ

拡張ストアド プロシージャの代わりにCLR 統合を使用する場合

Microsoft からの答えは、ほぼ常に次のようになります。

于 2013-01-22T11:57:31.137 に答える
0

SQL Server 2005 以降では、拡張ストアド プロシージャは使用しないでください。拡張ストアド プロシージャは推奨されておらず、不適切に記述されたものは、SQL Server に属する他のメモリに落書きしたり、破損したりする可能性があります。

CLR プロシージャを検討するのは、CPU を集中的に使用する必要があり、コードをコンパイルすることでメリットが得られるか、CLR ライブラリ ( System.Text.RegularExpressions. TSQL の方が効率的であるため、通常のデータ アクセス コードでは使用できません。

次のバージョンの SQL Serverからは、CLR の使用例がさらに少なくなる可能性があります

現在、SQL Server のクエリ プロセッサは、クエリとストアド プロシージャを一連のデータ構造にコンパイルし、SQL Server のクエリ プロセッサのインタープリターによって評価します。Hekaton を使用すると、T-SQL ストアド プロシージャのクエリと手続き型ロジックがマシン コードに直接コンパイルされ、コンパイル時に積極的な最適化が適用されます。これにより、ストアド プロシージャをネイティブ コードの速度で実行できます。

于 2013-01-22T11:58:08.090 に答える
0

私見：決して。拡張プロシージャーは長い間非推奨であり、将来の開発計画に含まれるべきではありません。

既存の拡張プロシージャを使用したり、 を介してコマンド ラインを呼び出しxp_cmdshellたり、SQL Server の境界外で操作したりする場合はいつでも、CLR を検討する必要があります。ただし、多くの場合、そもそも SQL Server 内でタスクを実行する必要があるかどうかも検討する必要があります。

string の分割など、SQL Server 内の計算プロセスで CLR が優れているユース ケースもいくつかありますが、そのような場合でも、 CLR を使用しないより優れた回避策があります。

于 2013-01-22T12:11:48.020 に答える