展望微软下一代数据库系统

核心提示： xml(标准化越来越近了)和Yukon数据库 对xml(标准化越来越近了)的支持开始于SQL 2000，这个版本的SQL可以将关系数据以xml(标准化越来越近了)形式返回；从xml(标准化越来越近了)批量载入数据；分享xml(标准化越来越近了)文档；将数据库对象发布成为基于xml(标准化越来越近了)的Web serv

xml(标准化越来越近了)和Yukon数据库 　　

　　对xml(标准化越来越近了)的支持开始于SQL 2000。这个版本的SQL可以将关系数据以xml(标准化越来越近了)形式返回；从xml(标准化越来越近了)批量载入数据；分享xml(标准化越来越近了)文档；将数据库对象发布成为基于xml(标准化越来越近了)的Web services。Web services的开发工具SQLxml(标准化越来越近了) 3.0对存储过程，xml(标准化越来越近了)，以及SQL的UDFs提供了Web services的支持。SQL 2000对于xml(标准化越来越近了)支持的不足之处在于缺乏内部的xml(标准化越来越近了)存储机制以及复杂的查询半结构化数据的能力。Yukon在这两个关键问题上有了长足的进步。 　　

　　xml(标准化越来越近了)数据类型 　　

　　xml(标准化越来越近了)是从一种表达型的技术演化而来，到现在xml(标准化越来越近了)以被视为一种存储信息的方式。如何保存xml(标准化越来越近了)变成了一个非常有趣的话题。xml(标准化越来越近了)文档可以在应用程序中有很多不同的使用。 　　

　　1．当你不知道xml(标准化越来越近了)规范（schemas ）的时候； 　　

　　2．当xml(标准化越来越近了)规范是动态变化的时候（dynamic schemas）； 　　

　　3．xml(标准化越来越近了)的保存是应用程序的中心。 　　

　　很难用一个例子来说明xml(标准化越来越近了)的应用方法和方式。在下文中给出的例子中，xml(标准化越来越近了)被作为一种存储形式，使用动态规范（dynamic schema）来表达客户从网上订户的信息。 　　

　　xml(标准化越来越近了)数据类型是一个很完备的（full-fledged）。它有其他SQL数据类型的一切能力。同时，作为一个完备的数据类型，xml(标准化越来越近了)是可以被索引的。它可以通过XSD schema对行和列的值加以限制（constraints）。它还可以被T-SQL中嵌入的XQuery查询。此外，使用xml(标准化越来越近了)dt::modify方法,用户可以增加，删除子树和更新标量值（update scalar values） 　

　　xml(标准化越来越近了)数据是非常灵活的。你可以选择是否要对这个xml(标准化越来越近了)列关联一个规范定义（xml(标准化越来越近了) Schema Definition，XSD）。如果你选择了XSD，那么这个列成为有类型的xml(标准化越来越近了)(typed xml(标准化越来越近了))。如果没有相应的XSD，那么这个xml(标准化越来越近了)称为没有类型的xml(标准化越来越近了)(untyped xml(标准化越来越近了))。输入XSD到一个表格的xml(标准化越来越近了)列，可以类型这个列。XSD可以被用来生成索引以及其他一些系统目录（system catalog）所需要的要信息。有类型的xml(标准化越来越近了)比没有类型的xml(标准化越来越近了)可以更快和更有效的操作。 　　

　　要注意的是你可以在一个列中存储整个xml(标准化越来越近了)文档或是其中的一部分。另外，你还可以对这个列生成特殊的xml(标准化越来越近了)索引。这样就对xml(标准化越来越近了)中的标签（tag）, 值（value）何路径（path）生成了索引。 　　

　　XSD and xml(标准化越来越近了)数据类型 　　

　　当创建你的xml(标准化越来越近了)列时，以可以加入XSD文档并将之和你的列联系起来。XSD schema的联系在SQL的Workbench中完成。（使用DDL也可以完成这一联系） 　

　　当一个schema输入到数据库中的时候，它会被分解为不同的组件（component），包括元素（ELEMENT），属性（ATTRIBUTE），类别（TYPE），属性群（ATTRIBUTEGROUP）等等。这些部分以及相关联的字域（namespaces）被存到系统的不同表格当中去。你可以用系统专用的视图来看这些组件。也就是说，schema不是原封不动被存储的。至少有两个分支产生。一是schema的标签（Tag）和属性没有被保存，二是一旦schema被输入到数据库中，它不能保证可以还恢复到原先的样子。所以你最好保存一份原先的schema，或是将其存放到一个专用的表格中去（对于这个任务，xml(标准化越来越近了)列就是非常胜任的）。另外一个办法是使用内置的函数xml(标准化越来越近了)_SCHEMA_NAMESPACE来得到xml(标准化越来越近了) schemas。 　　

　　当xml(标准化越来越近了)列和XSD schema组合的时候，xml(标准化越来越近了)数据的查询能力就是对普通关系数据的一个补充。将所有的数据保存为xml(标准化越来越近了)形式是不必要的，但是利用数据库的xml(标准化越来越近了)能力确实方便了xml(标准化越来越近了)文档的管理以及其他一些应用。 　

　　XQuery 　　

　　xml(标准化越来越近了)查询通常被称为XQuery。它是一种智能的可靠的语言，专门用于查询各种xml(标准化越来越近了)数据。使用XQuery, 你可以用相应的方法查询xml(标准化越来越近了)数据的变量和列。使用最新的创新性的查询方法，你可以对关系型数据以及xml(标准化越来越近了)数据进行统一查询。 　

　　我们知道xml(标准化越来越近了)有许多的标准。在Yukon的XQuery研发过程中尽量的遵循W3C的标准。XQuery的起源是个叫做Quilt的查询语言。它是一种基于多种技术之上的查询语言，比如XPath 1.0, XQL, and SQL。它同时还包括了XQuery 2.0的一部分。你可以继续使用你的XPath的知识，不过Yukon有了许多的增强，你也许想要学习这些新的东西。比如一些支持循环，排序等操作的新函数。　　

　　XQuery申明语句（Statement）包括一个导引和主体（a prologue and a body）。导引中包括一个或多个字域申明以及其他产生查询内容的规范（schema）的引用。主体包括一系列的表达式用来说明查询的条件。这些申明语句可以在query, value, exist, or modify这样几种方法中对使用。 　　

　　XQuery可以查询有类型的xml(标准化越来越近了)（typed xml(标准化越来越近了)），及有相应的规范(schema)的xml(标准化越来越近了),它还可以查询一般的xml(标准化越来越近了)文档 　　

　　微软的XQuery设计程序 -- XQuery Designer 　

　　XQuery Designer是一个继承在sql server(WINDOWS平台上强大的数据库平台) Workbench得一个应用程序，用以简化xml(标准化越来越近了)工作的难度。它可以帮助你写出对xml(标准化越来越近了)列以及xml(标准化越来越近了)文档查询的语句。其核心目的是使程序员不用大量学习xml(标准化越来越近了)的许多知识而容易的驾驭XQuery。

　　到这里，大家对Yukon中的.NET以及xml(标准化越来越近了)的能力有了一个大概的了解。组合使用这些技术可以很方便的解决以前认为是相当复杂的难题。Yukon的开发重点是分布式应用。商业应用的流程和逻辑将直接反映在数据库程序当中。Yukon还对基于Web的应用有非常好的支持。 　　

　　Yukon的服务代理（Service Broker） 　　

　　SQL数据库的服务代理可以让内部和外部的进程通过扩充的或是普通的T-SQL DML发送和接收有保证的，异步的消息。消息可以被传递到和发送者共享一个数据库的队列中去，或是同一个SQL进程的其他数据库中去，甚至是本机或是异机其他数据库进程的数据库中去。 　　

　　在以往的消息系统中，应用程序要负责消息的收发和协调工作。消息的复制，同步以及次序的维护都是比较棘手的问题。 　

　　SQL数据库的服务代理通过自动维护消息次序，唯一的发送和会话标志很好地解决了这一难题。一旦两个服务间的对话建立起来，两端的程序被保证一个消息只接收一次，并且接收顺序和发送顺序一致。这样你的程序不需要额外的语句就可以保证一个消息只被处理一次。SQL数据库的服务代理自动为每一个消息加上一个唯一的标志。一个应用程序总可以知道某个消息是属于哪一个会话。 　

　　服务代理将要发送的消息放到队列中去。如果接收方一时没有准备好，那么消息会被保存在这个队列中。服务代理不停的试发消息，直到消息被接收方受到为止。这样可以保证会话的可靠性。即使接收方在一段时间内没有响应，消息也不会遗失。这种发送和接收方松散连接的模式使得双方都有很大的灵活性。发送者只要将消息放到队列中就可以返回去继续他的工作。消息会由服务代理保证发送到接收方手里。一个消息可以发到多个接收者手里。这些接收者可以独立的并行处理消息。其快慢可以根据当时服务器负荷程度而定。 　　

　　队列还可以使得处理工作更均匀的分配，从而减少服务器负荷的大起大落。这样从总体上提高了应用的性能和吞吐量。比如说，订货的高峰总出现在每天中午。这种高峰增大了系统资源消耗，延长了处理时间。如果使用了服务代理，那么在接收订货的时候并不需要马上完成所有的处理工作。许多工作可以在后台慢慢处理。只要先保证客户的订单可以顺畅的收到就可以了。 　　

　　消息处理程序的一个难点就是如何实现让多个程序从同一个队列中并行读取消息。因为操作不当就会造成消息处理次序混乱，尽管收到的顺序是正确的。 　　

　　试想这样一个典型的应用。含有如何生成订货头部信息的A消息和含有如何生成订货明细条目的B消息被放置在一个队列中。如果他们被不同程序从队列中取走进行处理。很可能B消息的处理程序进行得快而首先试图确认（commit）。但是由于头部信息还没有准备好，所了确认一定会失败。这样B消息就会被重新放置到队列中等待再一次处理。这显然是一种浪费。以往对于这种问题的解决办法就是将A消息B消息合并为一个消息。对于简单的两个消息这种办法还可以，但如果对于有上百个消息的复杂情况，这种办法显然就不适用了。 　　

　　服务代理通过锁定属于一个任务(Task)的所有消息来解决这个难题。这样这些消息只能被一个处理程序接收和处理。而同时其他处理程序可以接收和处理属于其它任务的消息。这种机制保证多个处理程序可以可靠和有效的并行工作。　

　　服务代理的一个最有用的功能就是“激活”（activation）了。激活可以在收到消息的时候自动启动消息处理程序。如果消息来的速度大于处理的速度，那么多个消息处理程序就会被启动，直到达到了配置允许的最大值。如果消息来的速度减慢或是已经没有消息等待被处理了，那么消息处理程序将会被关掉。这样消息处理程序的数量将根据消息的数量和收到的速度自动动态的调节。如果系统崩溃或是重启动，在系统恢复过来以后，消息处理程序会自动启动来处理积压的消息。以前的消息处理系统做不到这一点，所以消息处理程序不是太多就是太少。 　

　　服务代理和数据库的集成 　　

　　集成的服务代理提供了性能上的以及管理上的好处。和SQL数据库的集成使得交易式的消息传递成为可能。也就是说消息接收，处理和返回这样一个循环变成了一个数据库的交易，如果中间有一个环节出现错误，所有的工作将会被放弃，接收到的消息重新进入处理队列以被再一次处理。直到交易最终完成以前，没有任何动作会产生效应。这样应用程序将始终保持一个一贯的状态，并且不会引入分布式交易处理的复杂性和过多的资源消耗。　

　　当数据，消息和程序的逻辑全部存在与数据库中的时候，管理工作也变得相对容易。象灾难恢复，簇建立（clustering），安全控制，备份这些管理工作只需要面对一种东西而不是3种或4种分散的组件。比如说，在以前的消息系统中，消息存储和数据库可能会出现不一致。如果其中一个从备份上恢复过来，那么另外一个也必须从同一时间的备份上恢复过来，否则数据就会变得不统一。当数据和消息被数据库统一处理后，这个问题就变得不再是问题了。 　

　　使用统一的开发环境也带来不少好处。应用程序的消息处理部分和数据存取部分可以用统一的语言来完成。对于已经熟悉数据库开发的程序员，这可以极大的降低消息处理部分开发的难度。实现服务代理的存储过程的可以用传统的T-SQL或是.NET兼容的高级语言来开发。 　　

　　另外，数据库的集成使得资源的自动管理成为可能。服务代理运行于SQL数据库的空间之中，这样代理就可以对该数据库进程中所有的已经传递的消息有一个集成的全局的视角。这样各个数据库可以维持自己的消息队列，而在全局上又尽可能保证资源分布的相对合理。 　　

　　Yukon数据库应用开发的一个具体实例 　　

　　我们假设有这样一个应用：用户在网上订购你公司的产品。这个在各个服务之间传递的消息存放在xml(标准化越来越近了)列中。为简易起见，我们把这个应用程序想象为SQL数据库中CLR运行的一个基于ASP.NET的Web service。这个服务和其他的伙伴传递客户订货的消息。使用xml(标准化越来越近了)列来存储消息可以封装和简化xml(标准化越来越近了)的Schema. 　　

　　当客户的订货确定后，包含这个订货信息的消息被放置到订货队列中去并放置在xml(标准化越来越近了)列中。这样这个订货的所有信息就被存放到一个列中。 　　

　　订货队列是交易得开始。他接到消息并处理它。它向信用校核服务发送一个请求。如果客户的信用没有问题，那么它就进行下一步的操作。 　　

　　下一步是检查现有的库存。一个XQuery来查询库存情况。如果有库存，那么操作走向下一步，发货。 　

　　在发货步骤中，一个T-SQL的存储过程使用XQuery来解读这个xml(标准化越来越近了)消息，客户的信息被提取出来以生成发货单。当发货完成后，这个消息就被转到收款服务处。 　　

　　但收款服务受到这个消息后，它更新客户订货的状态，指明货物已经被发送。 　　

　　另外，所有进出订货服务的消息都被写到一个审计表格中以备将来可能的审核以及错误更正。

　　从这个小例子中你可以看出，Yukon是如何集成使用xml(标准化越来越近了)，CLR，服务代理，增强的T-SQL来构建一个可靠的，可扩充的完备的数据库应用。 　　

　　结论： 　　

　　以上介绍的只是Yukon中一些令人振奋的新特色和功能。数据库开发人员如今有了更多的选择。上一个小例子示范了一部分Yukon中新增的能力。更多的特色和功能还有待于我们进一步挖掘！