Yukon 为 T-SQL 语言提供了更多新的语言构造和基元，这里无法一一列举。所有这些内容，您均可以在 SQL Server Yukon Books Online 中找到。对 T-SQL 语言的增强功能反映出对 ANSI-99 SQL 规范更有力地遵守，并且这些增强也是对用户请求的响应。T-SQL 中的许多改进主要集中在查询表达方式的改善方面。有几个新的查询类型允许用 T-SQL 代码处理常见情况。例如，递归查询提供了生成材料帐单或层次结构结果集的功能。

Yukon 中的 T-SQL 提供了新的 PIVOT 和 UNPIVOT 运算符。这些运算符对输入表值表达式执行操作，并生成一个输出表作为结果集。PIVOT 运算符可将行旋转为列，根据该思路可以选择性地执行聚合或其他数学计算。这就拓宽了基于给定旋转列的输入表表达式，并生成了一个输出表，其中的一列为旋转列中的每个唯一值。UNPIVOT 运算符执行的操作与 PIVOT 相反；它将列旋转为行。UNPIVOT 运算符收缩了基于旋转列的输入表表达式。

Yukon 引入了一种新的、简单的但更强大的异常处理机制，该机制采用 TRY/CATCH T-SQL 构造的形式。现在，便可以捕获和处理那些使批处理终止的事务中止错误了。此外，还有一些新的语言构造，用于安全、复制、通知服务、XML 以及 .NET 框架提供的所有功能。端的 .NET 框架实现是 SQL Server 产品周期中的重要进展。

现在，开发人员可以利用任意 Microsoft .NET 兼容的语言（包括 Visual Basic .NET 和 C#）编写存储过程、触发器和用户定义的函数 (UDF)。此外，三种新对象（用户定义的类型 (UDT)、聚合和函数）还可以用托管代码来创建。CLR 是 .NET 框架的核心，它为所有基于 .NET 框架的代码提供了执行环境。CLR 提供了执行所需的各种函数和服务，包括实时编译、内存管理和分配、类型安全强制、异常处理、线程管理以及安全。SQL Server Yukon 作为这一功能的宿主，就象操作寄主应用一样。

作为 CLR 集成的结果，Yukon 还提供了自动内存管理、资源分配和垃圾收集等功能。通过进入 SQL Server 执行空间，SQL Server 可提供 .NET 集对对象的直接访问。数据访问通过一种特殊形式的 ADO.NET 实现。本文不讨论中 ADO.NET 功能这一部分。但是，由于访问方法与那些开发人员熟悉的方法非常类似，因此使用 CLR 的功能很容易。

Yukon 将 .NET 框架与 SQL Server 集成的方式为开发人员提供了几个主要优势，包括：

增强的编程模型 CLR 兼容的语言在许多方面都远胜于 T-SQL，它为 SQL 开发人员提供了之前无法使用的构造函数和功能。此外，还提供了一组类库（框架 API），它比 SQL 本身提供的内置函数更丰富。

增强的安全性 托管代码在 CLR 中运行，寄主于引擎。这使 .NET 对象比以前版本的 SQL Server 中扩展的存储过程更可靠、更安全。

用户定义的类型和聚合 通过寄主 CLR，可以使用两个新的对象，它们扩展了 SQL Server 的存储和查询功能。

公共开发环境 开发集成是 Visual Studio .NET 开发环境的未来版本中已经纳入计划的功能。开发人员在开发和调试对象和脚本时，使用与编写中间层或客户层 .NET 框架组件和服务相同的工具。

性能和可伸缩性 在某些情况下，.NET 语言的编译和执行模型提供了比 T-SQL 更佳的性能。

在以前版本的 SQL Server 中，员在编写端代码时只能使用 T-SQL。借助 CLR 集成，开发人员现在可以执行仅使用 T-SQL 时不可能完成或很难完成的任务了。Visual Basic .NET 和 C# 都是现代的编程语言，它们提供对数组、结构化异常处理和集合的全面支持。与 T-SQL 所能支持的代码相比，开发人员能够利用 CLR 集成编写具有更复杂的逻辑、更适于计算任务的代码。

此外，Visual Basic .NET 和 C# 还提供面向对象的功能，如封装、继承和多态。现在，相关代码可以很容易地组织成类和命名空间。在编写上使用的大量代码时，这使您能够更轻松地组织和维护代码成本。这种在逻辑和物理上将代码组织成集和命名空间的能力是一项突出的优势，它使您能够在大型实现中更快地找到和关联不同的代码片段。

设计 UDT 时，您将需要考虑如是否可为空值和检查约束这样的问题。您甚至可以使用私有函数扩展数据类型的功能；例如，您可以在本机添加 XML 序列化功能。

此外，在注册后，集可以引用上的其他集。这意味着，您可以加载一个包含常用功能（该功能可由上的一个或多个其他集使用）的集。这可以增加通用代码的重用。开发人员肯定会欣赏这种模块化的方式，因为他们应用的对象模型将变得越来越大，越来越复杂。

SQL Server Yukon 实现了三种级别的安全性，可限制中已注册集的功能。此安全模型是两种安全模型的集成：SQL Server 安全模型，它以用户身份验证和授权为基础；CLR 安全模型，它在代码层使用了代码访问安全。

最高的安全级别 SAFE 只允许对数据进行计算和访问。第二级别 EXTERNAL_ACCESS 还允许访问外部资源。最低的安全级别 UNSAFE 除了会危及稳定性的操作之外，没有任何限制。

数据层中的托管代码允许您对对象执行数值计算和复杂的执行逻辑。.NET 框架为串处理、正则表达式、错误捕获等提供了广泛支持。此外，借助 .NET 框架基类库中的功能，开发人员现在可以完全访问成千上万个预建的类和例程，这些类和例程可以从任何存储过程、触发器或 UDF 轻松地访问。对于需要串处理、数学函数、日期操作、资源访问、高级加密算法、访问、图像处理或 XML 数据操作等情况，托管存储过程、函数、触发器和聚合提供了比 T-SQL 简单得多的编程模型。

托管代码的另一个优势是类型安全。在执行托管代码之前，CLR 将执行检查，以验证代码确实安全，可以运行。例如，检查代码的内存访问，以确保如果未写入到内存就不读取内存。

在编写存储过程、触发器和 UDF 时，员现在必须做出的一个决定就是，使用传统的 T-SQL 还是使用 CLR 兼容的语言（如，Visual Basic .NET 或 C#）。答案取决于具体项目的需要。T-SQL 最适用于代码主要是执行数据访问，很少或没有过程化逻辑的情况。CLR 兼容的语言则最适用于数学计算密集的函数和具有复杂逻辑的过程，或是需要在 .NET 框架基类库的基础上构建解决方案的情况。

代码替换是 CLR 集成的另一个重要功能。T-SQL 和 CLR 寄主的代码都运行在上的引擎中。将 .NET 框架的功能和紧密结合在一起，可让您充分利用的处理能力。我建议您使用 SQL Server 事件探查器来审查应用的性能，然后根据测试的实际结果做出自己的选择。SQL Server 事件探查器已进行了改进，可提供对 SQL Server 中 CLR 性能的深入探查，包括可用于比较的新的图形输出格式。

现在让我们看一看 .NET 框架的某些功能，以及它们是如何与 Yukon 相辅相成的。

Yukon 支持可扩展的 CLR 类型。这些类型在端可用作表定义的一部分，在客户端可作为对象来操作。UDT 使您能够通过创建在托管代码中实现的新类型，来扩展现有的类型。某些 UDT 示例为地理空间类型、自定义金融类型和特定日期／时间类型。可以将 UDT 看成是引擎和代码之间的协定。

在 .NET 术语中，UDT 是一个结构或引用类型，而不是类或枚举。这就是说内存的使用可以优化。但是，UDT 并不支持继承和多态。它即可以包含公共函数，也可以包含私有函数。事实上，像约束检查这样的任务应该作为私有类来完成。如果您的 UDT 由多个信息（例如，地理空间类型会包含经度、纬度可能还有海拔）构成，您就需要提供包含这些元素的私有字段。创建 UDT 之后，您可以使用 T-SQL 在 SQL Server 中注册类型。完成后，DLL 的内容就实际存储到中了。

UDF 有两个变体：标量值函数和表值函数。标量值函数返回单一值，如串、整数或比特。表值函数返回的是可以由一个或多个列构成的结果集。

能够创建中现有函数以外的其他聚合函数的能力，是使用旧版 SQL Server 的开发人员无法做到的。借助 Yukon，开发人员可以在托管代码中创建自定义聚合函数，并使这些函数能够被 T-SQL 或其他托管代码访问。用户定义的聚合也是一个要引用中已有集的 .NET 类。

您可以使用 UDAgg 将存储在中的数据转换为数学值。例如，一个统计函数。您可以存储包含来自一个关系表中量化调查结果的数据。为了计算出这些结果的加权平均值或标准偏差，您可以调用 UDAgg 来计算和返回这些信息。

作为存储过程工作的托管代码例程，最适用的情况是：将简单的结果集稍加修改后返回给调用方，或要简单地执行一个数据操作语言 (DML) 或数据定义语言 (DDL) 语句的场合。在上注册后，使用代码就和编写一个存储过程一样简单。

要使用存储过程包装一个托管代码方法，请使用 CREATE PROCEDURE 语句。CREATE PROCEDURE 使用以下原型中的语法：

XML 在 SQL Server Yukon 中的历史实际上始于 SQL Server 2000。该版本的 SQL Server 引入了以 XML 的格式返回关系型数据、大量加载和切分 XML 文档，以及将对象公开为基于 XML 的 Web 服务等功能。Web 服务工具包，也称为 SQLXML 3.0，为存储过程、XML 模板和 SQL Server UDF 提供了 Web 服务功能。该 XML 技术缺少了两个重要的部分：原生 XML 存储机制（XML 数据类型）和支持对半结构化数据进行查询的高级查询语言。Yukon 提供了这两个元素，以及更多的 Web 服务增强功能和对 T-SQL FOR XML 语句的扩展。让我们从原生 SQL Server 数据类型（XML 数据类型）的主要增强功能开始。

XML 从一种表示技术发展为一种线路格式，现在又被看作是一种存储格式。XML 中的持久存储已经引起了广泛关注，并出现了许多 XML 数据类型的可能应用。首先，XML 在不知道对象架构的情况下很有用。其次，XML 数据类型对于信息要不断重新组织情况中的动态架构很有用。第三，XML 持久性是 XML 文档应用的中心。没有什么单一的应用场景能够最好地体现 XML 数据类型的正确使用。稍后，我将在本文给出的编程示例中，将 XML 用作一种动态架构（以发送给的消息形式表示用户定单）的存储格式。

XML 数据类型是功能完善的数据类型。它具有 SQL Server 中其他类型的所有能力和功能。这一点的重要性怎么强调都不过分。作为一种功能完善的类型，XML 列可以进行索引，可以通过 XSD 架构（虽然不需要 XSD 架构）添加行和列的约束，还可以使用 T-SQL 中嵌入的 XQuery 表达式进行查询。这些功能都已追加到 XQuery W3C 规范中。此外，使用 xmldt::modify 方法，用户还可以添加子树、删除子树和更新标量值。

XML 数据类型很灵活。您可以选择是否要将 XML 架构定义 (XSD) 架构与一列相关联。当一个列具有 XSD 架构关联时，它就称为类型化 XML。如果没有 XSD 关联，它就是非类型化 XML。XSD 架构可用于在将 XML 列导入后，对其类型化。然后，它可以用来为目录创建索引和其他元数据。在查询时，类型化 XML 列比非类型化 XML 列更快，也更灵活。使用场景将决定 XML 列的类型，虽然大多数应用都偏向于 XSD 架构引用。

另请注意，您可以在同一列中存储 XML 文档和 XML 片段。此外，您还必须针对 XML 列创建特殊的“XML”索引。这将为标签、值和 XML 值中的路径创建索引。

创建 XML 列时，您应该添加一个 XSD 文档并将其与该列关联。XSD 架构关联是从 SQL Server Workbench 内部执行的。XSD 关联还可以使用 DDL：

将一个架构导入时，它被分析为各种类型的组件，包括 ELEMENT、ATTRIBUTE、TYPE（对于简单类型或复杂类型）、ATTRIBUTEGROUP 和 MODELGROUP。然后，这些组件以及所有关联的命名空间都将存储到各种表中。您可以使用专用的视图来查看这些组件。换句话说，架构不是原封不动地存储起来的。这至少包含两层意思。首先，架构标签及其关联的属性并未存储。而 XML 标签属性（targetNamespace、attributeFormDefault、elementFormDefault 等）都被重新分配给架构的组件。其次，SQL Server 不提供在导入后恢复和查看原始架构文档的功能。建议您保留一份所有架构的副本，或将它们的内容存储到专用的表中。为此，使用一个 XML 列就足够了。此外，您还可以使用内置函数 XML_SCHEMA_NAMESPACE (uri) 来检索 XML 架构。这将返回命名空间 uri 的内容。

当 XML 列和 XSD 架构组合在一起时，XML 数据的查询功能将是常规关系型数据和查询的补充。虽然我不建议您以 XML 的格式存储所有数据，但是能够在中使用 XML，还是使 XML 文档的管理和其他应用场景大大简化了。

现在数据已经存储好了，我将转到 XQuery 上来，因为不提它，我的讨论将是不完整的。

XML 查询语言，通常称为 XQuery，是一种为查询所有类型的 XML 数据而进行优化的智能、健壮的语言。借助 XQuery，您可以使用类型关联的方法，对 XML 数据类型的变量和列运行查询。通过调用查询方法，您可以在同一批中跨关系型数据和 XML 数据进行查询。

与许多 XML 标准一样，XQuery 的开发（目前还是一个工作草案）是在 W3C 的指导下进行的。Yukon 支持 2001 年 12 月 20 日到 2002 年 11 月 15 日之间的 XQuery 1.0 工作草案的一个静态类型化子集。要了解所有草案，请参阅 。

XQuery 是从一种称为 Quilt 的查询语言演变而来的，该查询语言以多种其他语言（如 XPath 1.0、XQL 和 SQL）为基础。它还包含一个 XPath 2.0 的子集。您可以在 XPath 中使用现有的技巧，而无需学习一门全新的语言。然而，SQL Server Yukon 中包含了一些超越 Xpath 的重要增强功能，如特殊的函数和对更好的迭代、结果排序和构造的支持。

XQuery 语句由一个前导和语句体组成。前导包含一个或多个命名空间声明，和／或为查询处理创建上下文的架构导入。语句体包含一个指定查询条件的表达式序列。然后，这些语句将用在前面提到的 XML 数据类型的一个方法（query、value、exist 或 modify）中。

XQuery 能够查询类型化 XML（与 XML 架构关联的数据）以及 XML 文档。

XQuery Designer 是一个新工具，它集成在新的 SQL Server Workbench 中，可以简化 XML 数据的使用。XQuery Designer 有助于编写查询，从 XML 列和 XML 文档中操作和检索数据。XQuery Designer 的中心开发主题就是使用户无需学习 XML Query 语言的细节就可以进行 XQuery 开发。有关运行中的 XQuery Designer，请参见server/art/XmlTCLRfig01.gif" target="_blank">图 1 所示。

到现在为止，我已谈论了 Yukon 的新增 .NET 功能和 XML 功能。结合使用这些技术，可以创造新的机会来解决流行领域（如电子商务）中的应用场景。SQL Server 开发最近的关注点在分布式应用上，其中业务工作流和逻辑都要在应用中表示。使用 Yukon 中构建的对基于 Web 的应用的强大支持，让我们深入探究一下此处讲述的新功能。

在过去 10 年中，电子商务应用的迅速发展，产生了对提高跨应用流程管理水平的需求。如果您构建过定单输入或在网上进行过购物，就会对工作流模型非常熟悉。当一个用户为一本书下定单时，必须向库存、发货和信用卡提交一个事务，然后必须通过另一个 Web 应用发送定单确认信息。等待这些流程中每一个过程的同步不是很能好地伸缩。过去，开发人员必须编写复杂的存储过程，并使用远程过程调用代码将消息排入队列。Yukon 为构建异步消息路由提供了一种新的、可伸缩的体系结构。

SQL Server 服务代理是一项 Yukon 技术，它允许内部或外部流程使用常规 T-SQL DML 的扩展来发送和接收有保证的异步消息。消息可以发送到与发送者共享的中的一个队列内、同一个 SQL Server 实例中的另一个内，或同一台上或远程上的另一个 SQL Server 实例内。

在传统的消息处理中，应用负责消息的排序和协调。消息复制、同步化和排序都是企业级数据必须处理的困难问题。

SQL Server 服务代理可通过自动处理消息序列、唯一传递和会话标识，来解决这些问题。当会话在两个服务代理终结点之间建立后，应用会按照消息发送的顺序，对每个消息只接收一次。应用可以按顺序处理一次消息，而无需附加代码。服务代理会自动在每个消息中添加标识符。应用始终可以分辨出特定消息所属的会话。

服务代理将消息排入队列以进行传递。如果目标服务不能立即获得，消息将重复发送服务和传递尝试，直到消息发送成功。这可允许一个会话在两个服务之间可靠地继续传递下去，即使一个服务在会话期间的某个时刻暂时不可用。

SQL Server 服务代理提供了启动方服务和目标服务之间的松耦合。服务可以将消息排入队列，然后继续它的应用处理任务，依赖 SQL Server 服务代理保证消息到达其目的地。这种松耦合带来了调度上的灵活性。启动方可以发出多个消息，并且多个目标服务可以并行地处理它们。每个目标服务都可以按自己的速度处理消息，这取决于目前的工作负荷。

排队还允许将处理更加均衡地分布，以降低所需的峰值能力。这可以整体提高应用的吞吐量和性能。例如，定单输入应用可能会在每天中午遇到请求增加的情况，这会导致资源的大量消耗和缓慢的响应速度。通过服务代理，定单输入应用在接收定单时不需要执行所有的定单处理。相反，应用可以输入定单，然后提交请求以进行后台处理，如付帐、发货和库存管理。后台应用可靠地执行一段时间的处理，同时定单输入应用继续接收新的定单。

在消息处理应用中最难实现的一件事情就是，允许多个并行地从同一个队列中读取。这样的情况将导致消息不按顺序处理，即使它们是按顺序接收的。

下面看一个传统的定单处理应用。消息 A 包含创建定单标头的相关指令，消息 B 包含创建定单行项目的相关指令，它们都是在队列中接收的。如果这些消息都被单独的服务实例取出队列，并同时进行处理，定单行项目事务可能会首先尝试提交，然后会因为定单还不存在而失败。失败会导致事务回滚，使消息又重新进入队列并再次处理，从而浪费了资源。传统情况下，这个问题是通过将消息 A 和消息 B 中的信息结合到一个消息中解决的。虽然这个方法对于这两个消息很直接，但是在涉及要协调几十个或几百个消息时，它很难伸缩。

服务代理通过自动锁定与同一任务有关的所有消息解决了这个问题，因此这些消息只能由一个服务实例接收和处理。同时，其他服务实例可以继续将与其他任务相关的消息取出队列并进行处理。这使多个并行服务能够可靠且高效地工作。

服务代理最有用的功能之一是激活。激活可以在消息到达时，自动启动一个服务，从队列读取消息。如果消息到达的速度比处理它们的速度快，就会启动服务的其他实例，直至达到配置的最大值。如果消息到达的速度减慢了，活动的服务将检查队列，如果发现没有消息需要处理，服务就会自己关闭。这使服务实例的数量能够随着服务负荷的更改进行动态地增加和减少。如果发生故障或重启，当恢复时，将自动启动服务来读取队列中的消息。传统的消息处理缺乏这种行为，经常在给定时刻使专用于某个特定队列的资源不是太多就是太少。

服务代理的集成设计为应用的性能和管理提供了许多优势。与 SQL Server 集成能够使用事务性消息处理；也就是说，一个服务的每个循环（接收消息、处理消息和发送回复消息）可以封装在一个事务中。如果事务失败，所有工作都会回滚，已经接收的消息会重新排入队列，以便进行另一次尝试对其进行的处理。在应用提交事务之前，所有操作都不会生效。应用会保持一致状态，而无需增加资源开销和分布式事务协调器的复杂性。

当数据、消息和应用逻辑都在中时，管理就更简单了。只有一项（而不是三个或四个单独的组件）需要为灾难恢复、群集、安全、备份等进行维护。例如，在传统的消息处理中，消息存储区和可能是不同步的。例如，当一个组件从备份中恢复时，另一个组件也必须同时从备份中恢复，否则消息存储区和就可能不一致。让消息和数据使用一个，这就不再是问题了。

使用公共开发环境也是一个优势。应用的消息处理和数据部分可以使用服务代理应用中的同一种语言和工具。这使开发人员对编程技术的熟悉扩展到了基于消息的编程。实现服务代理服务的存储过程可以用 T-SQL 或任一种以 CLR 为目标的语言编写。

此外，集成使自动资源管理成为可能。服务代理在 SQL Server 实例的上下文中运行，因此代理可以维护所有准备从实例的所有中传输的消息的聚合视图。这允许每个维护自己的队列，同时还能在跨整个 SQL Server 实例的资源使用上保持平衡。

让我们看看这些概念在定单输入应用中是怎样结合的，其中用户在一个 Web 站点下定单。在服务之间传送的消息存储在一个 XML 列中。为了说明问题，我将使用一个基于 ASP.NET 的 Web 服务，该服务已在 SQL Server 中由一个 CLR 的实例注册并寄存。该服务与一个合作伙伴通信，以发送和接收购买定单信息。使用消息的 XML 列可允许架构的封装和简化。

用户在 Web 站点上下定单。当定单事务提交后，包含定单信息的消息会放入定单输入服务队列中。定单将以 XML 列的形式发送给定单输入服务。这可将所有的定单信息合并到一列中。有关此流程的完整视图，请参见server/art/XmlTCLRfig02.gif" target="_blank">图 2。

定单输入服务启动事务，接收消息，然后处理它。然后，定单输入服务向信用限制服务发送一个请求，以验证信用状态。如果没问题，定单输入服务将执行下一步。

定单输入服务检查定单中每一项的库存。XQuery 会处理库存检查。此时，如果商品项可以发货，将向发货服务队列发送一个消息。

发货服务（一个 T-SQL 存储过程）使用 XQuery 分析 XML 消息。用户信息用于生成定单发货。当发货完成后，将向付帐服务队列发送一个消息。当付帐服务队列接收到“发货完成”的消息后，将更新中的定单状态，以表示定单已经发货。所有来自和发送到定单输入服务的消息都会写到一个审计表中，供以后分析和解决问题使用。

从这个简单的示例中，您可以看到如何使用新的 Yukon 可编程功能（XML、CLR、服务代理和 T-SQL 增强功能），来构建可靠、可伸缩和完整的应用。

我只是触及了 Yukon 中几个新的、激动人心的体系结构功能。开发人员从来都没有在数据访问和存储上获得这么多的选择。此 SQL Server 服务代理示例仅在结合 SQL Server 的新功能时着重说明了几项功能。开始使用 SQL Server Yukon Beta 版并继续关注 MSDN Magazine 未来的内容。只要有所了解，您就会使用 Yukon，而且再也不会走老路了。