微软的下一代数据库系统（代号Yukon）已经浮出水面。这一版本的数据库系统有不少的新特色。比如它使用的Transact-SQL将更加符合ANSI-99 SQL的标准，查询语句将更灵活，更富表达性。Yukon允许程序员用.NET的语言，比如C#,VB.NET来开发自定义函数（user-defined functions），存储过程（stored procedures）和触发（triggers）。另外它还支持W3的XQuery语言，支持XML等等。
在Yukon的酝酿和设计过程中，设计师对下一代数据库系统的编程能力下了很多气力。微软内部的开发人员认为，下一代的数据库系统一定要包括更多的对称编程模式，对各种数据类型的查询应该更灵活。所谓的对称编程模式是指对于常见的数据库操作，用户应该可以使用XML,.NET或是传统的T-SQL程序．
在这种设计思想的指导下，Yukon在许多方面有了大的拓展。首先，.NET的公用语言执行环境(CLR)被融合到了新的系统里；第二，融合进来的.NET提供了很多强有力的数据库对象；第三，XML在这版的数据库里得到了更好和更深的支持；第四，数据库的服务器端提供了对XML查询(XQuery)以及XML规范定义语言XSD的支持；第五，传统意义上的T-SQL也得到了进一步的增强
新的编程模式和新增的语言一道使得数据库应用的开发有了更丰富的选择。新的体系结构使得我们更容易构造可靠的，可扩展的，稳定的应用，并且开发的效率也得到了极大的提高。Yukon中还引入了全新的服务代理（Service Broker），一种分布式的一部消息传递机制，现在让我们先看看编程语言方面的增强。
Transact-SQL 语言的增强
Yukon对微软的T-SQL有了很多的增强。用户可以在Yukon的Online帮助中得到详细的信息，限于便服，在此不一一列了。新增的特色表明了微软对ANSI-99 SQL标准的进一步支持，同时也反映了对广大用户反馈意见的相应。新的增强主要是为了使查询更富有表达性。有几种新增的查询可以很好的覆盖用户常用的一些查询类型。比如说，递归查询可以返回有层次机构的结果集合（hierarchical resultset）或是a bill of materials。
Yukon提供了新的PIVOT和UNPIVOT操作。这些操作的输入是表格类的表达式（table-valued expression），其输出结果同样是表格类型。PIVOT操作是将行转变为列，并进行集合以及其他的数学操作。在输入的表格中它将以一个给定的列为轴进行旋转，其成生的表格的列是有不同值的原旋转列。这种操作使得生成的表格变宽（设想一个5列100行的输入表格，其结果可能是100列5行的表格）。UNPIVOT是PIVOT的逆操作。它将输入表格的列转换为行。其结果是使输入表格变窄。
Yukon的异常捕捉和处理机制也有了很大的变化。它使用了和.NET一致的TRY/CATCH结构。导致交易终止的错误将会被捕捉并且处理。另外为了配合.NET的框架提供的安全，复制，提示服务以及XML等等功能（security, replication, Notification Services, XML），Yukon引入了不少新的语言构造。.NET在服务器端的技术也极大了影响了SQL数据库的研制和发展。
在SQL服务器中使用.NET来编程
程序员可以在Yukon中使用和.NET兼容的高级程序语言进行开发，利用VB.NET，C#这一类的语言编写自定义函数（user-defined functions），存储过程（stored procedures）和触发（triggers）。另外，利用管理程序（managed code）还可以开发自定义函数（UDTs）,集合（aggregates），函数（functions）。公用语言执行环境（CLR）是.NET的核心，它是一切基于.NET开发的程序的运行平台。它提供了诸多的服务，比如实时编译(just-in-time compilation)，内存管理和分配(memory management and allocation)，类型安全强制(type safety enforcement)，异常处理(exception handling)，线程管理(thread management)以及安全检查(security)等等（CLR对于.NET程序就好比Java的虚拟机对于Java程序一样）。在Yukon中，.NET程序将和在CLR中完全相同的方式运行。
将CLR整合到Yukon中的好处是显而易见的。Yukon获得了CLR的各种有益的功能，如自动的内存管理，资源分配，垃圾回收等等。Yukon提供了一套.NET assemblies，这样允许程序员直接操作数据库对象。数据的操作是通过一套特殊的ADO.NET来实现的。这些新的方法和原来的ADO.NET非常相似，程序员应该感到非常的熟悉和亲切。细一点说，我们可以把Yukno集成了CLR的好处归结为以下几点：
1．丰富了编程模式。CLR兼容的高级程序语言比T-SQL要丰富的多，也强大的多。它们提供的功能和特色是以往SQL程序员不敢想象的。此外，Yukon还提供了一系列的类库（Framework APIs），这些类库的功能比以前SQL内置的功能强大的多。
2．增强了安全性。管理程序运行于数据苦支持的CLR环境当中。这使得数据库的对象比以往的扩展存储过程（extended stored procedures）更安全。
3．用户自定义的类型和集合。通过对CLR的集成，这两个新增的对象扩展了SQL数据库的查询和存储能力。
4．为今后的Visual Studio®开发环境指明了方向。今后程序员可以向开发其他.NET程序那样用VB.NET或是C#这类的高级语言进行数据库的开发，调试工作。
5．性能的增强。在一些情况下，.NET语言的编译和执行可以提供比T-SQL更好的性能。
充分开发CLR的潜能
在以前的SQL数据库应用的开发中，服务器端的程序被限制于T-SQL。而在新的Yukon中，由于集成了CLR，使得开发工作变得前所未有的容易和方便。像VB.NET和C#这类的高级语言，全面支持数组（Array），结构化的异常处理（structured exception handling）以及各种集合操作（Collections）。这些功能使得程序员可以编写更复杂的逻辑和计算工作。
更突出的一点就是Visual Basic .NET and C# 是面向对象的语言，它们自身所具有的数据封装（encapsulation），继承（inheritance）和多态性（polymorphism）是T-SQL所不能比拟的。在大型系统的开发中，这种基于模块化开发机制的优越性会更加明显。它可以更好的组织你的源程序，增加代码的重用性。将源程序按照逻辑关系编译成不同的assemblies和n字域（namespaces）可以增强程序的组织性，让程序员更方便的浏览和使用已有的程序。
Yukon实现了三个层次的assemblies安全的管理控制。这种安全机制是对以往基于用户验证和授权机制和新的CLR安全机制的有机合成。新的三级管理层次为：
最高层次: 安全接触（SAFE）。它只允许接触和计算数据
次高层次: 外部接触（EXTERNAL_ACCESS）。它允许接触外部的系统资源
最低层次: 不安全接触（UNSAFE）。只要不对系统的稳定性造成影响，就不加限制。
在T-SQL和管理程序（Managed code）之间的取舍
管理程序非常适于进行数字密集型的计算和复杂的逻辑处理。.NET对于字符串 (String)，规则表达式（regular expressions），错误捕捉等等有着更好的支持。另外.NET提供的上千个类(Class) 和方法可以在自定义函数（user-defined functions），存储过程（stored procedures）和触发（triggers）中很方便的使用。所以对于有大量字符创操作，数学计算，日期运算，系统资源存取，高级加密运算，文件操作，图像处理或是XML的情形，管理的存储过程，函数，触发，集合要比传统意义上的T-SQL等强大和简洁。
使用管理的程序的另外一个好处就是类型安全。在管理的程序执行之前，CLR要对其进行检查以保证它的安全运行。比如说，对于一个内存读写的操作，CLR要先进行检查以保证在读取的时候没有写操作在进行。
在准备编写存储过程，触发，或是UDFs之前，你要权衡各种情况，在传统的T-SQL和管理程序（Managed code）之间做出选择。选择的标准是你当前问题的具体特点。如果你的主要操作是数据存取以及相对简单的逻辑运算，那么T-SQL则非常合适。对于有大量数值计算以及复杂逻辑运算的情况，管理程序（Managed code）则更适用。
程序放置在什么地方也是很关键的一步。T-SQL和管理程序（Managed code）都是在数据库的引擎内运行。把.NET和数据库紧密放置在一起可以有效的发挥服务器的硬件运算能力。当然最好是用SQL数据库的Profile程序来测量一下你的具体程序的运行性能，然后再做出决定。Yukon的Profile程序有了进一步的增强。可以更深层次的测量SQL数据库内的CLR的性能，并且会以更直观的图形方式来输出对比测试结果。下面就让我们来具体看看Yukon中新增的一些功能。
用户定义的类，函数和集合（User-defined Types, Functions, and Aggregates）
Yukno支持扩展的CLR的类系统。这些扩展的类可以在服务器端定义表（table），也可以在客户端进行数据操作。用户自定义类型（UTDs）允许用户扩展已有的类。这些扩展的具体实现是用的管理程序（managed code）。比如说，你可以定义一些用于地理空间的类型，一些特殊的金融类型或是特别的时间日期类型以适应你独特的要求。
用.NET的术语来说，UTDs是结构（struct）或是参考类型（reference type），而不是类（class）或枚举（enum）。这意味着内存的是用是由CLR控制优化的。不过，UTDs不支持继承和多态性（inheritance and polymorphism）。它可以有公用或是私有函数（public and private functions）。事实上，诸如限制检查（constraint checking）应该由私有函数来完成。举例来说吧，如果你想定义一个地理空间的类型，这可能包含经度，纬度也许还有高度信息，你可以定义相应的私有成员来完成这一任务。这类型创建完成后，你可以把他注册到SQL数据库中。这个被编译的DLL就会被存放在SQL数据库中。
用户自定义函数（UDFs）有两种类型：一种是标量值型的（scalar-valued），这种函数返回单一的值，如字符串，整数，比特等等。另外一种是表格值型的（Table-valued）。这种函数返回有一个或多个列组成的数据集合。
Yukon允许用户定义新的集合（aggregate）操作的能力远远超过了以前的版本。用户用管理语言开发的集合可以被T-SQL或是其他的管理语言调用。这些新开发的集合是.NET的类，它可以引用数据库中存在的其他编译好的类库（Class Library）。你可以使用用户定义的集合将数据库中的数据转化为数值型变量。比如你最近的一次用户调查的数据存放到数据库中，通过一个用户定义的统计函数你可以得到加权平均或是标准偏差。
管理的存储过程
这是一种管理程序，其工作方式就像传统的存储过程一样。如果你希望返回一个简单的数据集和（resultset）或是只是进行一个数据操作（使用DML或是DDL）。一旦被注册到数据库中，那么使用它就像是用一个普通的存储过程那样。将一段管理程序包装成存储过程的语法如下（基于现在早期的Yukon版本）
CREATE PROCEDURE mysproc (@username NVARCHAR(4000))
AS
EXTERNAL NAME YukonCLR:[MyNamespace.CLRCode]:: myfunction
(未完）
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查询。此外，使用xmldt::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 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中新增的能力。更多的特色和功能还有待于我们进一步挖掘！