Planification des notifications
Pour utiliser efficacement les notifications de requêtes, vous devez déterminer si votre application peut tirer parti des notifications de requêtes et si les requêtes que votre application utilise prennent en charge les notifications. Il vous faudra ensuite définir la stratégie que votre application suivra pour s'abonner aux notifications ou en recevoir.
Les notifications de requêtes constituent un moyen efficace de réduire les va-et-vient vers la base de données si les données de la requête changent relativement peu souvent, si l'application ne demande pas une mise à jour instantanée en cas de modification des données et si la requête répond aux exigences et aux limites présentées dans Création d'une requête pour notification. Bien des applications Web répondent à ces critères et peuvent donc tirer parti des notifications de requêtes.
Les scénarios ne profitent pas tous des notifications de requêtes. Les notifications de requêtes sont utiles lorsqu'une application lit fréquemment les données de la base de données, mais que les mises à jour des données sont plutôt rares. Par exemple, un catalogue en ligne sera consulté plus fréquemment qu'il ne sera mis à jour. En revanche, pour un panier d'achat en ligne, le contenu d'un panier particulier pourra être mis à jour assez souvent et, dans ce cas, les notifications de requêtes n'apportent pas autant d'avantages.
Les notifications de requêtes sont plus efficaces lorsqu'une application émet des requêtes qui partagent une structure commune et ne se distinguent que par les valeurs des paramètres. Par exemple :
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 300
SELECT ProductNumber, Name FROM Production.Product WHERE ListPrice < 500
Dans ce cas, les abonnements aux notifications de requêtes partagent le même modèle interne pour les deux notifications ; la charge placée sur SQL Server est donc moindre que s'il s'agissait de deux notifications avec une structure de requête différente. Sachez, toutefois, que les paramètres des requêtes sont conservés. Bien que les requêtes partagent un modèle, l'ajout d'un élément à un ListPrice de 350 engendre une notification sur la deuxième requête, mais pas sur la première.
Lorsque les notifications de requêtes sont actives sur une table, les mises à jour apportées à la table sont plus coûteuses. Le Moteur de base de données réalise un travail supplémentaire pour vérifier les abonnements et, le cas échéant, générer des notifications. En réutilisant les modèles internes, il est possible de diminuer la charge par abonnement. Veillez par conséquent à n'activer les notifications de requêtes que pour les applications soumettant des requêtes de structure similaire. Une application qui soumet des requêtes de structure différente ne doit pas faire appel aux notifications de requêtes.
Par exemple, une application qui affiche les articles d'un catalogue, classés par gamme de prix, soumet des requêtes de même structure. Dans ce cas, le Moteur de base de données peut réutiliser le modèle interne pour chaque requête, et les notifications de requêtes permettent d'optimiser les performances. En revanche, une application qui permet la création d'un état à la demande soumet des requêtes de structure variable. Mieux vaut, dans ce cas, ne pas recourir aux notifications de requêtes.
Le Moteur de base de données conserve un modèle interne aussi longtemps qu'il est utilisé par un abonnement enregistré au minimum. Le Moteur de base de données limite le nombre de modèles internes différents sur une table particulière. Une fois cette limite atteinte, le Moteur de base de données n'enregistre plus les abonnements susceptibles d'engendrer la création d'un modèle. En revanche, le Moteur de base de données génère immédiatement un message indiquant que l'abonnement n'a pas pu être enregistré.
Voir aussi
Concepts
Création d'une requête pour notification