剖析SQL Server 2005查询通知之基础篇

一. 引言

　　数据库应用程序的典型问题之一是更新陈旧的数据。

　　设想有一个典型的显示产品及其分类的电子商务网站。一个供应商的产品列表很可能并不经常发生变化，而其分类列表甚至更不会频繁更改。然而，在用户每次浏览该网站时，必须从数据库中反复查询这些列表。这显然是一种典型的低效资源利用，开发者和架构师都在绞尽脑汁想办法以减少这种浪费。

　　缓冲技术正是“最小化”对这种几乎“停滞”的数据进行重复查询的技术之一。这种数据可以被进行一次性查询并存储在一个缓冲区中，而且应用程序可以从缓存中重复地存取数据。偶尔情况下，才更新缓存以得到新数据。但是，围绕更新缓存的时间调度方面出现了几个问题。该多长时间操作一次呢？例如，你每隔多长时间希望你的产品分类改变一次？每隔几个月一次？每隔两个月刷新一次该缓冲区如何？你知道会发生什么吗？就在你刷新缓存之后，分类被更新，而且在下一次刷新前在两个月的时间里它将保持陈旧。

　　查询通知，是微软的ADO.NET和SQL Server小组协作开发的新成果。简言之，查询通知允许你缓冲数据并且仅在SQL Server中的数据发生变化时才发出通知。一旦接到通知，你就可以刷新你的缓冲区或者采取你需要的任何措施。

　　在SQL Server 2005中引入的一种新特征“Service Broker”使得查询通知成为可能。Service Broker把队列机制引入到数据库管理中，它使用一组队列与服务进行通讯，而服务反过来也知道如何往回通讯以调用相应的实体。其实，这些队列和服务都是一些与表、视图和存储过程一样的类对象。尽管完全可以在SQL Server内使用Service Broker，但是ADO.NET知道如何与Service Broker进行通讯以触发这种机制并且从Service Broker中检索回通知。

　　注意 当SQL Server中的数据发生改变时，查询通知允许你缓冲数据并且通知你。

　　在.NET一端，存在很多种“钩入”这种功能的方式。ADO.NET 2.0提供了System.Data.SqlClient.SqlDependency和System.Data.Sql.SqlNotificationRequest类。SqlDependency是SqlNotificationRequest的一种高级实现，并且是当使用ADO.NET 2.0时你最有可能使用的类。ASP.NET 2.0也通过System.Web.Caching.SqlCache-Dependency类(它提供了一个针对SqlDependency的包装器)与Service Broker进行通讯，而且这是直接通过在一个ASP.NET页面中使用<%OutputCache>指令以声明方式提供的功能实现的。这允许ASP.NET开发者容易地实现使依赖于SQL Server中的数据中的缓存无效。

　　二. .NET与Service Broker的通讯

　　上面这些技术是如何联合到一起来解决“缓冲之谜”的呢？尽管你可以采取很多的措施以允许SQL Server把服务提供给.NET；但是，关键还在于，发送到SQL Server的查询具有一个依附到它们的标志以便告诉SQL Server，除了返回结果集外，SQL Server还应该把该查询（及其请求者）注册到Service Broker。为此，你要创建一个感知该查询的队列和一个依附到该队列的服务，并且知道如何返回到客户端。如果该结果集中的任何一行在数据库中得到更新，那么在相关队列中的项将触发，并且反过来，把一条消息发送到它的服务，然后把一个通知发送回初始化该请求的应用程序。

　　图1是SQL Server Management Studio的一个快照，它显示了在数据库的Service Broker部分中的队列（Queues）和服务（Services）。

图1.该图显示了.NET的查询通知所使用的Pubs数据库中的缺省队列和服务。

　　下面是理解这一过程的一些有关重要内容：

　　· 存在一些规则以指出SQL Server接收哪些类型的查询。

　　· 一旦SQL Server发送回通知，队列和服务即被删除。这意味着，你仅能在每次请求中得到一个通知。一个典型的应用程序会重新查询数据库并且，在同时，请求在Service Broker中创建一种新的依赖性。

　　· 返回到应用程序的信息也不过是“something changed”。该应用程序并不被通知改变了什么（请参考本文中的SQLNotificationEventArgs一节了解更多的信息）。

　　· 尽管依赖性被绑定到从查询中返回的行上；但是，它并不被查询中的单个列加以过滤。如果你有一个查询—它返回你的组织的基本成员姓名以及那些单个改变之一的地址（但是，其姓名并不改变），这将触发一个改变通知。很希望，这种特殊行为在未来的版本中会有所改变。

　　· 通知被返回，通过一个专门针对这一目的建立的SqlConnection。这个连接并不加入连接池中。

　　三. 何时使用查询通知

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

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

　　注意：对于客户端应用程序来说，应该限制你的查询通知使用—不多于十个并发用户。

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