SqlDependency vous avertira uniquement qu'un changement s'est produit et vous devrez relire l'intégralité du tableau. Cela fonctionne bien avec un faible taux de notifications. A un rythme élevé, il faut considérer que les notifications ont un coût non négligeable. Voir La notification mystérieuse pour plus de détails sur le fonctionnement de SqlDependency. Comme vous pouvez le voir, il y a un coût important :
- configuration de la notification (écriture dans sys.dm_qn_subscriptions et dans les tables système SSB)
- déclenchement de la notification (écriture sys.dm_qn_subscriptions)
- livrer la notification (écritures dans les tables système SSB, file d'attente cible)
- réception de la notification (écritures dans la file d'attente cible, tables système SSB)
Cela représente un certain nombre d'écritures, le coût augmentera rapidement si vous êtes constamment averti.
Mais la vraie question est de savoir comment exactement voulez-vous réagir dans l'application à un taux de changement constant ? que voulez-vous savoir, ce quelque chose modifié? eh bien, vous savez, c'est toujours le cas, chaque fois que l'application a besoin des données, il vaut mieux lire le dernier état, car il a certainement changé. Les sondages n'ont pas non plus de sens. On dirait que ce que vous voulez vraiment est soit change suivi ou, plus probablement, une file d'attente de modifications personnalisée alimenté par les auteurs du changement.
