SqlDependency与SQLCLR调用WebService

Question

我有一个桌面应用程序，应该通知任何表更改。所以，我发现只有两种解决方案适合我的情况：SqlDependency和SQLCLR。 （我想知道是否有更好的.NET堆栈）我已经建立了这两个结构，并使他们的工作。我只能比较从SQL Server到客户端的响应的持续时间。

的SqlDependency

持续时间：从100毫秒到4秒

SQLCLR

持续时间：从10毫秒到150毫秒

我希望这个结构能够处理高利率通知*，我已经阅读了一些SO和博客文章（例如：here），并且我从一位同事也警告说，大量请求SqlDependency可能会出错。 Here，MS提供了我没有得到的东西，这可能是我的问题的另一种解决方案。

*：并非所有的时间，但一个赛季;在1-2台服务器上每秒处理50-200个请求。

根据通知率高和表现平行的基础，我应该继续哪一个，还是有另一种选择？

Answer 1

SqlDependency（即查询通知）或SQLCLR（即通过触发器调用Web服务）都不会为该业务量（每秒50-200个请求）工作。事实上，这两个选项在这些卷中都是相当危险的。

在两个链接页面（SoftwareEngineering.StackExchange.com和TechNet文章中的链接页面）中给出的建议都是更好的选择。关于Best way to get push notifications to server from ms sql database（即每隔几秒轮询一次的定制队列表）的建议与TechNet文章（使用Service Broker处理队列处理）的文章Planning for Notifications的选项＃1非常相似。

我喜欢排队的想法（完全自定义或使用Service Broker）最好，并且已经在高度事务性的系统上使用完全自定义队列（很容易获得预期的体积）并取得了很大的成功。这两个选项之间的利弊（因为我看到他们，当然）是：

• 服务代理
  • 临：现有（和经过验证的）框架（可扩展和绑成交易）
  • 缺点：并不总是容易的配置或管理/调试，不能容易聚集200个个别事件以1秒到单个消息（将仍然是每每个触发事件1个消息）
• 完全定制队列
  • Pro：可以将许多同时发生的触发事件合并为单个“消息”给客户端（即，轮询服务可以检测自上次轮询以来发生的任何更改），可以使用更改跟踪/更改数据捕获作为“更改内容”的来源，因此您可能不需要构建队列表。 Con：只有像你可以做到的那样可扩展（可能与Service Broker一样好，或者更好，但高度依赖于你的技能和经验来实现这一目标），需要对边缘案例进行彻底测试确保队列处理不会错过或重复计数事件。

您也许能够服务代理与更改跟踪/变化检测相结合。如果有足够简单的方法来确定最后一次处理的更改（如更改跟踪/更改数据捕获表中所述进行更改），则可以设置SQL Server代理作业以每隔几秒进行一次轮询，如果您发现新的更改已经进入，然后将所有这些更改转换为单个消息发送给Service Broker。

有些文档，让你开始：

• Track Data Changes（既包含更改跟踪和变更数据捕获）
• SQL Server Service Broker