通知の計画
クエリ通知を効果的に使用するには、アプリケーションにはクエリ通知によるメリットがあるかどうか、アプリケーションが使用するクエリが通知をサポートしているかどうか、アプリケーションはどのように通知のサブスクライブや受信を行うかを検討する必要があります。
クエリ通知は、クエリのデータの変更頻度が比較的少ない場合、データが変更されてもアプリケーションですぐにデータを更新する必要がない場合、またはクエリが「クエリ通知の作成」で説明されている要件や制限を満たしている場合に、データベースとアプリケーション間のやり取りを削減することができます。Web ベースのアプリケーションの多くは、この条件を満たしています。このようなアプリケーションでは、クエリ通知を利用できます。
クエリ通知は、すべてのシナリオにメリットがあるとは限りません。クエリ通知は、アプリケーションがデータベースのデータを頻繁に読み取ったとしても、データの更新頻度が比較的少ない状況で役に立ちます。たとえば、オンライン カタログ アプリケーションは、読み取られる頻度の方が、カタログが更新される頻度よりも高くなります。一方、オンライン ショッピング カートでは、特定のコンテンツが極めて頻繁に更新されるので、クエリ通知によるメリットは少なくなります。
クエリ通知は、アプリケーションが共通の構造を持ち、パラメータ値のみが異なるクエリを実行する場合に、効果が高くなります。次に例を示します。
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 300
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 500
この場合、どちらの通知に対するクエリ通知のサブスクリプションでも、同じ内部テンプレートが使われるので、クエリ構造の異なる 2 種類のクエリの通知を要求する場合に比べて、SQL Server のオーバーヘッドが小さくなります。ただし、クエリのパラメータは保持されることに注意してください。クエリは同じテンプレートを使用していてますが、ListPrice が 350 のアイテムを追加した場合、2 番目のクエリは通知を生成しますが、最初のクエリは通知を生成しません。
テーブルでクエリ通知がアクティブな場合、テーブルの更新にはより多くのリソースが使用されます。データベース エンジン が、サブスクリプションを確認し、必要に応じて通知を生成するという余分な作業を行うことになるためです。内部テンプレートを再利用すると、1 サブスクリプションあたりのオーバーヘッドを最小限に抑えることができます。したがって、同様の構造を持つクエリを送信するアプリケーションでのみ、クエリ通知を使用することをお勧めします。構造の異なるクエリを送信するアプリケーションでは、クエリ通知を使用しないことをお勧めします。
たとえば、特定の価格帯のカタログ アイテムを表示するアプリケーションは、同じ構造のクエリを送信します。この場合、データベース エンジン は、各クエリに同じ内部テンプレートを再利用できるので、クエリ通知を使用することでパフォーマンスが向上する可能性があります。一方、アドホック レポートを許可するアプリケーションは、構造の異なるクエリを送信します。この場合は、アプリケーションでクエリ通知を使用しないようにします。
データベース エンジン は、登録済みのサブスクリプションの 1 つでも内部テンプレートが使用される限り、その内部テンプレートを保持します。データベース エンジン は、ある特定のテーブルで使用できる内部テンプレートの種類の数が制限されます。この制限に達すると、データベース エンジン は新たにテンプレートが作成される原因となり得るサブスクリプションを登録しなくなります。代わりに、データベース エンジン は、サブスクリプションを登録できなかったことを示すサブスクリプション メッセージを直ちに生成します。