如何通知Windows服务(c#)的DB Table Change(sql 2005)？

查询通知.这是支持SqlDependency及其衍生产品的技术,您可以在The Mysterious Notification上阅读更多详细信息.但QN旨在使结果无效,而不是主动通知更改内容.你只会知道表有变化,不知道有什么改变.在繁忙的系统上,这将无法正常工作,因为这些通知将会持续不断.

日志阅读这是事务复制所使用的,是检测更改的最简单的方式.不幸的是仅适用于内部组件.即使您设法了解日志格式,问题是您需要引擎支持,将日志标记为“正在使用”,直到您读取它,否则可能会被覆盖.只有事务复制才能做这种特殊的标记.

数据比较.依靠时间戳列来检测更改.也是基于拉,相当凶猛,并有检测删除的问题.

应用层这是理论上的最佳选择,除非在应用范围之外的数据发生变化,在这种情况下,它会崩溃.实际上,在应用范围之外总会发生变化.

触发.最终,这是唯一可行的选择.基于触发器的所有更改机制的工作方式相同,它们将更改通知排队到监视队列的组件.

总是有一些建议,要做一个紧密耦合的同步通知(通过xp_cmdshell,xp_olecreate,CLR,通知WCF,你命名它),但所有这些方案在实践中都失败了,因为它们有根本的缺陷：
– 它们不考虑事务一致性和回滚
– 它们引入了可用性依赖关系(OLTP系统无法继续,除非通知的组件在线)
– 它们执行得非常可怕,因为每个DML操作必须等待某种形式的RPC调用才能完成

如果触发器实际上并没有主动通知侦听器,而只是排队通知,则在监视通知队列时出现问题(当我说’queue’时,我的意思是任何充当队列的表).监视意味着拉入队列中的新条目,这意味着将检查的频率与更改的负载进行正确平衡,并对加载尖峰进行响应.这根本不是微不足道的,实际上是非常困难的.但是,在SQL服务器中有一个语句具有阻止的语义,而不会拖动,直到更改可用：WAITFOR(RECEIVE).这意味着Service Broker.你在你的帖子中多次提到SSB,但是你是正确的,因为很大的未知数,所以害怕部署它.但现实情况是,到目前为止,你最适合你所描述的任务.

您不必部署完整的SSB架构,其中通知一直传递到远程服务(即使是Express Express也需要远程SQL实例).您需要同谋的所有方法是从通知发送之时(提交更改后)解除变化检测到的时刻(DML触发).为此,您需要的是本地SSB队列和服务.在触发器中,您可以将SEND更改通知给本地服务.在原始DML事务提交之后,服务过程activates并使用CLR传递通知.您可以在Asynchronous T-SQL看到类似于此的示例.

如果您沿着这条路径走下坡路,那么您需要学习实现高吞吐量的一些技巧,并且您不得不在SSB中排序发送消息的概念.我推荐你阅读这些链接：

> Reusing Conversations
> Writing Service Broker Procedures
> SQL Connections 2007 Demo

关于检测变更的手段,SQL 2008显然增加了新的选择：Change Data Capture and Change Tracking.我强调“显然”,因为它们不是真正的新技术. CDC使用日志读取器,并且基于现有的事务复制机制. CT使用触发器,与现有的合并复制机制非常相似.它们都适用于需要同步的偶尔连接的系统,因此不适合实时更改通知.他们可以填充更改表,但是您将留下任务来监视这些表的更改,这些更改完全来自您所在的位置.