データに対してどのような検証を行う必要があるかについて具体的な例がないため、これは非常に一般化された質問であり、一般化された推奨事項以上のものを提供することは困難です. その時点までに、SQLCLR (または SQL Server 内の CLR 機能) と T-SQL に関する一般的な情報を次に示します。
同じ操作を実行する場合、単純な T-SQL がCLR ルーチンよりも常に高速であるということは絶対にありません。T-SQL はデータ言語であり、文字列操作やその他の機能を実行するのに最適であるとは限りません。私はこの問題に関して、simple-talk に関するかなり詳細な分析を公開しました:
http://www.simple-talk.com/sql/t-sql-programming/clr-performance-testing/
データは SQL 経由でのみ取得または操作できるため、単純な T-SQL ほど高速ではない、または不可能な計算も実行しない場合、.Net 言語で SELECT または DML ステートメントをラップするだけでは実際の利点はありません。 . SQLCLR ルーチンは、データベース オブジェクト (テーブル、ビューなど) と対話するためにデータベース接続を開く必要があります。また、context_connection を使用している場合でも、コードが SqlCommand で単純な T-SQL を実行するだけであれば、これは、SQLCLR の悪い設計/使用です。
SQLCLR は、T-SQL の代わりと見なされるべきではありません。T-SQL では操作の効率が低下するか、操作が不可能な特定の場所で支援できるツールとしてアプローチする必要があります。sp_OACreate などを使用して機能を拡張できる場合もありますが、それには独自の問題があります。私は、T-SQL で実行するのが容易でない、可能でない、または効率的でない特定のアルゴリズムが、.Net から T-SQL に、ユーザー定義関数とストアド プロシージャから呼び出すストアド プロシージャを介して公開されるという中間点を持つことが最善であることを発見しました。 T-SQL コード。これを行うための関数と手順のライブラリを作成しました。これは SQL# (SQLsharp) と呼ばれ、ほとんど無料で、http ://www.SQLsharp.com/ で見つけることができます。
これらすべてを念頭に置いて、あなたの状況は次のとおりです。
新しい行が挿入されるとすぐに、テーブル内のすべてのデータ行を検証する必要があります。
...
テーブルに挿入されたすべての行は一連の検証ルールを通過する必要があり、これらのルールは行内のデータに基づいて異なる場合があります。
「挿入された」テーブルに対して、ストレート T-SQL とおそらくいくつかの SQLCLR ルーチン (実行されている特定の検証に応じて) の組み合わせを使用する、通常の T-SQL INSERT、UPDATE トリガーをテーブルに配置するのに最も適しているように思えます。繰り返しますが、検証に使用している特定のアルゴリズムによっては、CLR でより適切に実行されるものについては、これらのアルゴリズムの一部を 1 つの .Net ルーチンに組み合わせて、外部ルーチン。
もちろん、トリガーが最適かどうかは、INSERT と UPDATE の頻度、実行される検証の数、および数年以内にテーブルに含まれる行の数によって異なります。DML の頻度が非常に高い場合や行数が多い場合は、切断されたアプローチの方が適している可能性がありますが、検証アルゴリズムの実装方法に関する推奨事項は変わりません。検証に時間がかかりすぎる場合 (DML 操作を長時間停止してブロックを発生させたくない場合) は、トリガーを使用して、SQL を実行する別のキュー テーブルにキー値を格納できます。ジョブは数分ごとに処理し、保持するかどうかを決定できます。
冒頭で述べたように、検証の例は、各アルゴリズムを処理するのに最適な場所に関するより良い推奨事項を可能にしますが、この情報が、より良い決定を下すために必要なものを提供することを願っています.
そして、特定のアルゴリズムに対してどのアプローチがより高速であるかは、テストすることによってのみわかることを忘れないでください!