私の現在の見解はノーです。Transact SQL ストアド プロシージャの方が軽量で (おそらく) パフォーマンスが高いため、CLR プロシージャを使用すると開発者はあらゆる種類のいたずらを行うことができます。
しかし最近、非常によく書かれていない TSQL ストアド プロシージャをデバッグする必要がありました。いつものように、元の開発者が実際の TSQL の経験がなく、ASP.NET / C# に焦点を当てていたため、多くの問題が見つかりました。
そのため、CLR プロシージャを使用すると、まずこのタイプの開発者にとってより使い慣れたツールセットが提供されます。次に、デバッグおよびテスト機能がより強力になります (つまり、SQL Management Studio ではなく Visual Studio)。
単純な選択ではないように思われるので、あなたの経験を聞くことに非常に興味があります.
適切に作成され、よく考えられた T-SQL と CLR の両方の場所があります。一部の関数が頻繁に呼び出されず、SQL Server 2000 で拡張プロシージャが必要な場合は、CLR がオプションになることがあります。また、データのすぐ隣で計算などを実行することも魅力的かもしれません。しかし、新しいテクノロジーを投入して悪いプログラマーを解決するのは、悪い考えのように思えます。
CLR ストアド プロシージャは、セットベースのクエリを置き換えるものではありません。データベースにクエリを実行する必要がある場合でも、SQL を通常のコードに埋め込んでいるかのように、CLR コードに組み込む必要があります。これは努力の無駄です。
CLR ストアド プロシージャは、主に次の 2 つの目的で使用されます。1) ファイルからの読み取りや MSMQ でのメッセージのドロップなどの OS との対話、および 2) 複雑な計算の実行 (特に、.NET 言語で記述されたコードが既にある場合)計算を行います。
SQL Server 内で CLR をホストすることは、データベース開発者がタスクを達成するためのより柔軟なオプションを提供することを目的としています。他の人が述べたように、SQL は一連のデータの操作と変更に最適です。複雑なビジネス ルールやドメイン ルールを使用して大規模なアプリケーション開発を行ったことがある人なら誰でも、これらのルールの一部を純粋な SQL を使用して (場合によっては単一のマクロ クエリに) 適用しようとすると、本当に悪夢になる可能性があると言うでしょう。
手続き型またはオブジェクト指向の方法でより適切に処理できる特定のタスクがあります。ロジックのシーケンスを分割するために .NET コードを使用する選択肢があることで、クエリ操作の読み取りとデバッグが容易になります。CLR ストアド プロシージャを使用したことで、デバッガーをステップ実行すると、データベース レベルで起こっていることを簡単に追跡できるようになります。
ほんの一例ですが、ここでは動的検索クエリの「ゲートウェイ」として CLR ストアド プロシージャを頻繁に使用します。最大 30 の異なる検索パラメーターを持つことができる検索要求を考えてみましょう。ユーザーは 30 個すべてを使用するわけではないので、渡されるデータ構造には 30 個のパラメーターがありますが、ほとんどが DBNULL です。明らかなセキュリティ上の理由から、クライアント側には動的ステートメントを生成するオプションがありません。結果として得られる動的ステートメントは、外部の「エクストラ」を恐れることなく内部的に生成されます。
一般に、データベースとのインターフェースをあまり必要としないものがある場合は、CLR を使用します。したがって、値を解析またはデコードしているとしましょう。これは CLR で行う方が簡単で、値を返します。
CLR で複雑なクエリを実行しようとするのは、適切な方法ではありません。
ところで、これは 2008 年も変わりませんでした。
ファイル システムへのアクセス (CLR プロシージャが非常に有利な場合) は別として、私は T-SQL プロシージャを使用します。特に複雑な計算がある場合は、その部分を CLR関数に入れて、proc 内から呼び出すことができます (udf は、CLR 統合が本当に優れていることがわかった場所です)。そうすれば、タスクの特定の部分で CLR 統合の利点が得られますが、ストアド プロシージャ ロジックはできるだけ多く DB に保持されます。
私はそれらの 2 つが同等ではないと信じています.互いに対決するのに適しています.
CLR 統合は、昔の「拡張ストアド プロシージャ」を段階的に廃止することになっています。私たちの職場にはこれらのいくつかがあります...基本的に、従来のDBストアドプロシージャ/ T SQLを介して行うには難しすぎる/不可能だったSQLデータに対する処理/ロジックのブロックです。そこで彼らは、同様に呼び出すことができる C++ DLL の拡張ストアド プロシージャとしてそれを作成しました。
現在、それらは段階的に廃止されており、CLR 統合が代替品です。
あなたが言ったことを考えると、開発者がCLRでt-sqlタスクを実行できるようにすることでパフォーマンスにさらに大きなダメージを与えるよりも、開発者にt-SQlとデータベース全般について適切にトレーニングしてもらいたいと思います。データベースを理解していない開発者は、データベースのパフォーマンスに最適な方法で物事を行うことを避けるための言い訳としてそれを使用します。
それは常に仕事に適したツールに帰着するため、達成しようとしていることに大きく依存します.
ただし、一般的なルールとして、CLR プロシージャはオーバーヘッドが大きく、T-SQL のようなセット操作では決して実行されないことは間違いありません。私のガイドラインは、必要なものが T-SQL で過度に複雑にならない限り、すべて T-SQL で行うことです。次に、T-SQL アプローチが機能するようにさらに努力します。:-)
CLR プロシージャは優れており、確かにその役割を果たしますが、その使用は例外であり、規則ではありません。
件名に関するSQL Server Books Onlineのページには、次の利点がリストされています。
より優れたプログラミング モデル。.NET Framework 言語は多くの点で Transact-SQL よりも豊富で、以前は SQL Server 開発者が利用できなかった構造と機能を提供しています。開発者は、プログラミングの問題を迅速かつ効率的に解決するために使用できる広範なクラス セットを提供する .NET Framework ライブラリの機能を活用することもできます。
安心・安全の向上。マネージ コードは、データベース エンジンによってホストされる共通言語ランタイム環境で実行されます。SQL Server はこれを利用して、以前のバージョンの SQL Server で使用できた拡張ストアド プロシージャに代わる、より安全で安全な代替手段を提供します。
データ型と集計関数を定義する機能。ユーザー定義型とユーザー定義集計は、SQL Server のストレージとクエリ機能を拡張する 2 つの新しいマネージド データベース オブジェクトです。
標準化された環境による合理化された開発。データベース開発は、Microsoft Visual Studio .NET 開発環境の将来のリリースに統合されます。開発者は、データベース オブジェクトとスクリプトの開発とデバッグに、中間層またはクライアント層の .NET Framework コンポーネントとサービスを作成するために使用するのと同じツールを使用します。
パフォーマンスとスケーラビリティが向上する可能性があります。多くの場合、.NET Framework 言語のコンパイルおよび実行モデルは、Transact-SQL よりも優れたパフォーマンスを提供します。
通常の SQL プロシージャで CLR 関数が何千回も呼び出される状況に遭遇しました。これは、別のシステムからデータをインポートするためのプロシージャでした。関数はデータを検証し、null を適切に処理しました。
TSQL で操作を行った場合、proc は約 15 秒で終了しました。CLR 関数を使用した場合、proc は 20 ～ 40 分で完了しました。CLR 関数はよりエレガントに見えましたが、私たちが知る限り、CLR 関数を使用するたびにスタートアップ ヒットがありました。そのため、1 つの CLR 関数を使用して大規模な操作を行う場合でも、操作に比べて起動時間が短いため問題ありません。または、CLR 関数を適度な回数呼び出すと、関数のすべての呼び出しの合計起動時間は短くなります。ただし、ループには注意してください。
また、保守性のために、本当に必要以上の言語を持たない方がよいでしょう。
同様の質問に次の回答を投稿しました: Advantage of SQL SERVER CLR。ただし、C# / VB.net / etc が T-SQL よりも使いやすい言語であることは、T-SQL よりもSQLCLR を使用する理由にはならないことをここに追加します。T-SQL で何かを達成する方法がわからない場合は、まず T-SQL ソリューションを見つけるための支援を求めてください。存在しない場合は、CLR ルートに進みます。
SQL Server 内での SQLCLR / CLR 統合は、特定の問題 (すべてではない) の解決に役立つツールの 1 つです。純粋な T-SQL で実行できることよりも優れていることがいくつかあり、SQLCLR を介してのみ実行できることがいくつかあります。SQL Server Central の記事、SQLCLR レベル 1 への階段: SQLCLR とは何ですか? を書きました。（そこで記事を読むには無料の登録が必要です）、それはこの質問に対処します. 基本は次のとおりです (詳細については、リンクされた記事を参照してください)。
OPENQUERY/なしOPENROWSET)OPENQUERY/なしOPENROWSET)PRINT、重大度= 0 ～ 10) -- 記事でこれについて言及するのを忘れていました ;-)。RAISERROR考慮すべきもう 1 つの点は、アプリケーション コードにアクセスするためだけに内部専用のカスタム画面を作成しなくても、DB が特定のビジネス ロジックを把握できるように、アプリケーションと DB の間でコードを共有できると有益な場合があることです。たとえば、顧客からデータ ファイルをインポートし、ほとんどのフィールドのカスタム ハッシュを使用して、その値を DB の行に保存するシステムに取り組んできました。これにより、アプリが入力ファイルから値をハッシュし、行に格納されているハッシュ値と比較するため、データを再度インポートするときに行を簡単にスキップできました。それらが同じである場合、どのフィールドも変更されていないことがすぐにわかったので、次の行に進みました。これは単純な INT 比較でした。しかし、ハッシュを行うためのアルゴリズムはアプリのコードにしか含まれていなかったため、顧客のケースをデバッグするため、または少なくとも 1 つのフィールドに変更 (アプリからの変更) がある行にフラグを付けてバックエンド サービスに一部の処理をオフロードする方法を探すためかどうかに関係なく、新しいインポート ファイル内の変更を探すのではなく)、私にできることは何もありませんでした。これは、通常の処理ではなくても、DB にかなり単純なビジネス ロジックを含める絶好の機会でした。DB にエンコードされた値があり、その意味を理解することができないと、問題の解決が非常に難しくなります。これは、通常の処理ではなくても、DB にかなり単純なビジネス ロジックを含める絶好の機会でした。DB にエンコードされた値があり、その意味を理解することができないと、問題の解決が非常に難しくなります。これは、通常の処理ではなくても、DB にかなり単純なビジネス ロジックを含める絶好の機会でした。DB にエンコードされた値があり、その意味を理解することができないと、問題の解決が非常に難しくなります。
コードを記述せずにこれらの機能の一部を実際に見てみたい場合は、SQL#の無料バージョン(私が作成者です) には、正規表現関数、カスタム集計 (UDA)、カスタム タイプ (UDT) などがあります。
言及されていない可能性がある CLR を使用するいくつかの理由を追加します。