アプリケーションのアイデアはありますが、理想的には、サーバーが SQL ステートメントを処理する前に SQL ステートメントを交差させて、他のコードを最初に実行できる、MSSQL 用の一種の「SQL 書き換え」エンジン (HTTP サーバーが「URL 書き換え」モジュールを持つことができるのとほぼ同じ方法) を作成できることに依存します。
これは MSSQL でも可能でしょうか、それとも目標を達成するために別の方法を探す必要があるでしょうか?
答え1
問題は、書き換えを「どのように」行うかではなく、「どこで」書き換えを行うかです。IIS のようなものにしたいとのことですが、これは MSSQL では不可能です。IIS には要求処理パイプラインがあり、このパイプラインにカスタム コードを挿入できるポイントが多数あります (つまり、独自の ISAPI 拡張機能、HTTPModule、Global.asax のイベントを作成するなど)。
SQL Server には、開発者向けに開かれた SQL パイプラインはありません。SQL 要求が SQL Server に届いた場合、それを書き換えることはできません。元のクエリでテーブル名を置き換える場合、更新/挿入/削除の BEFORE または INSTEAD OF トリガーでは問題は解決されません。このテーブルが存在しない場合は、トリガーでカスタム ビジネス ロジックを実行できるようになる前に例外が発生するためです。
ただし、カスタム データ プロバイダー (ADO.NET アプリケーションがある場合) を作成することにより、クライアント (SQL サーバーではなく) で SQL を「書き換える」ことができます。MSDN - .NET Framework データ プロバイダーの実装これは簡単な作業ではなく、多大な労力を必要とします。コードでは、標準の MSSQL データ プロバイダー (System.Data.SqlClient) のほとんどの標準機能を再利用し、SQL を解析して特定のコマンドを置き換える関数のみをオーバーライドできます。
ぜひご覧くださいhttp://sqlfaultretryprovide.codeplex.com/- このプロジェクトは、自動的に「エラー時に再試行」機能を提供できる SQL Server へのカスタム .NET データ プロバイダーを構築することでした。したがって、これは SQL リライターではありませんが、独自のリライターを構築するための例として使用できます。
答え2
答え3
おそらく、SQL にビジネス レイヤーを作成することを検討しているのでしょう。既存のアプリを変更しようとしている場合、SQL アダプターはすべて独自のものであるため、問題が発生する可能性がありますが、アプリを変更できる場合は、DB 上に配置するビジネス レイヤーを作成し、共有メモリ接続を使用して SQL サーバーへのコマンドを処理できる可能性があります。
もう 1 つのオプションは、SQL を入力すると編集され、SQL データベースに対して実行される魔法の CLR ストアド プロシージャです (共有メモリよりもさらに高速なコンテキスト接続を使用)。
ただし、SQL サーバーは非常によく記述されているので、あなたが実現しようとしているようなことは、おそらく API を使用してクライアント側で実現するのが最善でしょう。そうすることで、処理がクライアントの数によって分散され、SQL サーバーが実際に実行される SQL を最適化できるようになります。
答え4
.net クラスを使用するトリガーを記述できます。
http://www.15seconds.com/issue/041006.htm
http://aspalliance.com/1273_CLR_Triggers_for_SQL_Server_2005.all
http://www.google.com/search?rlz=1C1_____enUS397US397&sourceid=chrome&ie=UTF-8&q=sql+.net+trigger
幸運を。