データベース テーブルを監視するサービスを (おそらく c# で) 作成したいと考えています。レコードがテーブルに挿入されると、サービスが新しく挿入されたデータを取得し、それを使用して複雑なビジネス ロジックを実行します (TSQL には複雑すぎます)。
1 つのオプションは、サービスが定期的にテーブルをチェックして、新しいレコードが挿入されているかどうかを確認することです。そのようにすることの問題は、挿入が発生するとすぐにサービスにそれを認識させたいことであり、データベースのパフォーマンスを低下させたくないということです。
少し調べてみると、CLR トリガーを作成すればうまくいくようです。挿入が発生したときに起動するトリガーを C# で記述し、新しく挿入されたデータを Windows または WCF サービスに送信できます。
SQL CLR トリガーの適切な (または可能な) 使用方法は何だと思いますか?
これを達成する方法について他のアイデアはありますか？
おそらく、挿入から後処理を分離する必要があります。
Insert トリガーで、レコードの PK をキュー テーブルに追加します。
別のサービスで、キュー テーブルから読み取り、複雑な操作を実行します。終了したら、レコードを処理済みとしてマークするか (エラー/ステータス情報と共に)、レコードをキューから削除します。
あなたが説明しているものは、ジョブ キューまたはメッセージ キューと呼ばれることがあります。これを行うために DBMS テーブル (およびその他の手法) を使用する方法については、検索で見つけることができるスレッドがいくつかあります。
とにかくトラブルに巻き込まれやすいデータベース機能の不適切な使用として、トリガーでこれを行うことを検討します。トリガーは、低オーバーヘッドの dbms 構造機能 (詳細な参照整合性チェックなど) に最適であり、軽量で同期的である必要があります。それは可能ですが、おそらく良い考えではありません。
SQL Server Service Brokerを呼び出すトリガーをテーブルに配置して、別のスレッドですべての作業を実行するCLRストアドプロシージャを（非同期で）実行することをお勧めします。
データベースを毎分ポーリングするサービスがありますが、パフォーマンスの問題はそれほど多くなく、クリーンなソリューションです。さらに、サービスまたは他の wcf エンドポイントがそこにない場合、トリガーが失敗するか失われ、とにかく後でポーリングする必要があります。
CLR トリガーや、これに何らかのトリガーを使用することはお勧めしません。重大な保守性と潜在的なロックの問題が発生する可能性があります。(挿入後に@@identityを気にせず、監査/キューテーブルをロックしない場合は、監査/キューテーブルに物を入れる非常に単純なトリガーが受け入れられる場合があります)
代わりに、アプリケーション/orm からキュー テーブルへの挿入をトリガーし、このキューを定期的に処理する必要があります。これは、ORM にトランザクションを設定するか、ストアド プロシージャを開始してトランザクションを開始し、変更をコミットしてアトミックに監査/キューに入れることで実行できます。（ここでのロックには注意してください）
すぐにアクションが必要な場合は、テーブルで挿入/更新/削除を実行した後、ジョブを生成してキューをクリアすることを検討してください。
また、バックグラウンド プロセスが適切に開始されなかった場合に備えて、キューを 1 分に 1 回程度再確認してください。それが Web アプリであり、スレッドの生成を回避したい場合は、バックグラウンド プロセスと通信してキューをクリアすることができます。
ストアド プロシージャに挿入を実装し、挿入後のプロシージャでビジネス ロジックを実行しないのはなぜですか? T-SQL で記述できないほど複雑な理由は何でしょうか。