浅析SQL Server 2005中的主动式通知机制

核心提示： ◆打开一条新的不经过数据库连接池的到SQL Server 2005的连接；◆在服务器上创建一个新的队列，并赋予唯一名称；◆在该队列上创建一个唯一名称的服务；◆在服务器上创建一个新的存储过程，浅析SQL Server 2005中的主动式通知机制(5)，在客户端不再监听队列时，清除掉上述的临时

◆打开一条新的不经过数据库连接池的到SQL Server 2005的连接；

◆在服务器上创建一个新的队列，并赋予唯一名称；

◆在该队列上创建一个唯一名称的服务；

◆在服务器上创建一个新的存储过程，在客户端不再监听队列时，清除掉上述的临时创建的各种对象；

◆侦听队列所收到的更改通知。

【注意】在上面的例子中，尽管你可以通过SqlCommand实例中的SQL更改记录，但并没有自动更新列表框内的记录数据，而是在收到SQL Server记录改变的通知后，通过事件触发指到OnDenpedencyChanged函数调用主线程重新执行ListProducts方法，从相关数据表读取更新后的记录来重设列表框的内容。

四、何时使用主动式通知机制

查询通知是针对于并不经常改变的数据而设计的。最好把它应用于服务器端的应用程序(例如ASP.NET或remoting)而不是客户端应用程序(例如Windows表单应用程序)。记住，每一个通知请求都要在SQL Server中注册。如果你拥有大量的都有通知请求的客户端应用程序，那么这可能会导致你的服务器产生资源问题。鉴于此，微软推荐，对于客户端应用程序，你应该限制使用查询通知的最大并行用户数不多于十个。

对于大规模应用程序来说，查询通知可能是一种强有力的帮助，而不用简单地添加越来越多的服务器以满足要求。设想，有一家大型的为成千上百万用户提供在线软件更新服务的软件公司。不是使每一个用户的更新操作都触发服务器上的另一个查询来确定需要哪些组件，而是能够缓冲查询结果并且可以直接从该缓存中服务匹配的查询。

对于较小规模的情况而言，下拉式列表框是另一种典型的数据集；此时该数据集更新的次数一般不如请求的次数多。产品列表、州列表、国家列表、供应商、销售人，甚至更多不太需要频繁改变的信息正是使用上述通知机制的较好候选。

五、小结

尽管查询通知是.NET 2.0中最重要的特征之一，但是目前它仍然难与其它优秀特征（例如ASP.NET中的泛型或UI魔术等）相衔接。然而，无论你使用它来防止针对于含有数百个项的下拉列表框的连续的反复查询，还是使用它来管理基于Web的上百万的客户端计算机的更新，它都能有效地帮助你减少资源开支。就其最简单的应用来看，借助于ASP.NET OutputCache指令（或通过在你的Web应用程序的中间层或Web服务中构建一种复杂缓冲的机制），查询通知可以成为创建可扩展的具有响应性的应用程序的强有力的协作开发工具。

【另注】本文基于SQL Server 2005 Express Edition调试通过。另外，尽管查询通知可以与SQL Server Express（SSE）一起使用，但是SSE数据库必须是一个命名的实例(命名的实例是安装选项之一)。