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

 

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

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

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

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

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

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

　　三. 何时使用查询通知

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

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

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

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

四. 为使用查询通知作预备

　　因为默认情况下SQL Server 2005处于高度安全的状态，所以你需要“打开”一些功能才能使用查询通知。首先，你要使用的每一个数据库都需要启动Service Broker功能。为此，你可以在T-SQL中使用如下命令实现：

USE mydatabase ALTER DATABASE mydb SET ENABLE_BROKER

　　另外，你需要授予一些SQL Server权限以答应非治理员帐户能够参与使用查询通知。

　　五. SqlDependency.Start和Stop

　　SqlDependency和SqlCacheDependency都要求，在任何通知请求前先调用静态方法SqlDependency.Start()。这个方法负责创建一个SqlConnection以实现在数据改变时接收通知。注重，你仅需要在一个应用程序的生命周期的开始建立这些内容。例如，在一个ASP.NET应用程序中，global.asax文件的Application_Start事件处理器就是实现这一功能的好地方。
共5页: 上一页 [1] 2 [3] [4] [5] 下一页

评论加载中…