SQL Server 2005中XML数据建模简介

　　关系或 xml 数据模型

　　如果您的数据是高度结构化的，具有已知的架构，则关系模型可能对于数据存储最为有效。microsoft sql server 提供了您可能需要的必要功能和工具。另一方面，如果结构是灵活的（半结构化和非结构化）或未知的，则必须适当地考虑如何对此类数据进行建模。

　　如果您需要独立于平台的模型，以便确保使用结构化和语义标记的数据的可移植性，则 xml 是一种不错的选择。而且，如果满足下列某些属性，则它还是一种适当的选择：

　　• 您的数据比较稀疏，或者您不了解数据的结构，或者数据的结构将来可能发生重大更改。

　　• 您的数据表示容器层次结构（与实体中的引用相对），并且可能是递归的。

　　• 您的数据具有内在的顺序。

　　• 您希望对数据进行查询，或者基于其结构更新部分数据。

　　如果上述任一条件都不满足，则您应该使用关系数据模型。例如，如果您的数据是 xml 格式，但您的应用程序很少使用数据库来存储和检索数据，则 [n]varchar(max) 列就能满足您的全部需要。在 xml 列中存储数据可以带来其他好处 - 引擎将检查数据格式规范或者有效，并且支持对 xml 数据进行细粒度的查询和更新。

　　在 sql server 2005 中存储 xml 数据的理由

　　以下为一些使用 sql server 2005 中的原生 xml 功能而不是在文件系统中管理 xml 数据的理由：

　　• 您希望使用数据库服务器的管理功能来管理 xml 数据（例如，备份、恢复和复制）。

　　• 您希望以高效的方式和事务处理方式来共享、查询和修改 xml数据。细粒度的数据访问对于您的应用程序而言很重要。例如，您可能需要提取 xml 文档内部的某些节，或者您可能需要插入一个新节而不是替换整个文档。

　　• 您具有关系数据和 sql 应用程序，您希望在应用程序内部的关系数据和 xml 数据之间进行互操作。对于跨域应用程序，您需要有关查询和数据修改的语言支持。

　　• 您希望服务器能够保证数据格式规范，并能够视情况根据 xml 架构来验证数据。

　　• 您需要将 xml 数据编入索引以便实现高效的查询处理和良好的可伸缩性，并且使用一流的查询优化器。

　　• 您希望对 xml 数据进行 soap、ado.net 和 ole db 访问。

　　如果不满足上述任一条件，您最好将数据存储为非 xml 的大型数据类型，如 [n]varchar(max) 或 varbinary(max)。

　　xml 存储选项

　　sql server 2005 中的 xml 的存储选项如下所示：

　　• 本机存储采用 xml 数据类型：

　　用能够保留数据的 xml 内容（如容器层次结构、文档顺序、元素和属性值等等）的内部表示形式存储数据。具体说来，就是保留 xml 数据的信息集内容（有关信息集的详细信息，请参阅 http://www.w3.org/tr/xml-infoset）。它可能不是文本 xml 的精确副本，因为未保留以下信息：无关紧要的空格、属性顺序、命名空间前缀和 xml 声明。

　　对于类型化的 xml 数据类型（即绑定到 xml 架构的 xml 数据类型）而言，负责向信息集添加类型信息的后架构验证信息集 (post schema validation infoset, psvi) 以内部表示形式编码。这会显著提高分析速度。

　　• xml 和关系存储之间的映射：

　　使用带有批注的架构 (axsd)，xml 将被分解到一个或多个表中的列，并且在关系级别保留数据的保真度 - 保留层次结构，但忽略元素顺序。架构不能是递归的。

　　• 大型对象存储（[n]varchar(max) 和 varbinary(max)）：

　　存储了数据的精确副本。这对于特殊用途的应用（如法律文档）很有用。大多数应用不要求精确副本，xml 内容（信息集保真度）即可满足需要。

　　通常情况下，可能需要组合使用这些方法。例如，您可能需要用 xml 数据类型列存储 xml 数据，并将其中的属性提升到关系列中。相反，您可能希望使用映射技术，将非递归部分存储到非 xml 列中，而仅将递归部分存储到 xml 数据类型列中。

　　xml 技术的选择

　　xml 技术（原生 xml 与 xml 视图）的选择通常取决于下列因素：

　　• 存储选项：

　　您的 xml 数据可能更适合于大型对象存储（例如，产品手册），或者更适合于存储在关系列中（例如，转换到 xml 的行项目）。每个存储选项都在不同程度上保留了文档保真度。

　　• 查询功能：

　　基于查询的性质以及对 xml 数据进行查询的程度，您可能发现一个存储选项比其他存储选项更为适合。细粒度的 xml 数据查询（例如，xml 节点上的谓词计算）在这两个存储选项中受到不同程度的支持。

　　• 将 xml 数据编入索引：

　　您可能希望将 xml 数据编入索引，以便提高 xml 查询性能。索引选项随存储选项的不同而不同；您需要进行适当的选择以优化工作量。

　　• 数据修改功能：

　　某些工作量涉及到对 xml 数据进行细粒度的修改（例如，在文档内添加新节），而其他工作量则不涉及（例如，web 内容）。对于您的应用程序而言，数据修改语言支持可能很重要。

　　• 架构支持：

　　您的 xml 数据可能通过架构进行描述，这可能是也可能不是 xml 架构文档。对架构绑定 xml 的支持取决于 xml 技术。

　　不用说，不同的选择具有不同的性能特性。

　　原生 xml 存储

　　可以将您的 xml 数据存储在服务器的 xml 数据类型列中。在下列情况下，这将是一个适当的选择：

　　• 您需要一种在服务器上存储 xml 数据的简单方法，同时需要保留文档顺序和文档结构。

　　• 您的 xml 数据可能有也可能没有架构。

　　• 您需要查询和修改您的 xml 数据。

　　• 您需要将 xml 数据编入索引以便实现更为快速的查询处理。

　　• 您的应用程序需要系统目录视图以管理您的 xml 数据和 xml 架构。

　　当您的 xml 文档具有多种结构时，或者当您的 xml 文档符合不同的或复杂的架构，而这些架构很难映射到关系结构时，原生 xml 存储将很有用。

　　示例：使用 xml 数据类型对 xml 数据进行建模

　　考虑一个 xml 格式的产品手册，其中每个主题对应单独的一章，而每章内又有多节。一节可以包含多个子节，因此 是一个递归元素。产品手册包含大量混合内容、图表和技术资料；数据是半结构化的。用户可能希望对感兴趣的主题执行与上下文有关的搜索（例如，在有关"索引"的章内部搜索有关"聚集索引"的节），并且查询技术数量。

　　xml 文档的合适存储模型是 xml 数据类型列。这可以保留 xml 数据的信息集内容。将 xml 列编入索引可以提高查询性能。

　　示例：保留 xml 数据的精确副本

　　假设政府法令要求您保留 xml 文档（例如，已签署的文档、法律文档或股票交易订单）的精确文本副本。您可能需要将您的文档存储在 [n]varchar(max) 列中。

　　对于查询，可在运行时将数据转换为 xml 数据类型，然后对其执行 xquery。运行时转换可能代价高昂，尤其是在文档很大时。如果您经常进行查询，可以采用冗余方式将文档存储在 xml 数据类型列中并将其编入索引，同时从 [n]varchar(max) 列返回精确的文档副本。

　　xml 列可能是基于 [n]varchar(max) 列的计算列。您不能在 xml 计算列上创建 xml 索引，也不能在 [n]varchar(max) 或 varbinary(max) 列上生成 xml 索引。

　　xml 视图技术

　　通过在 xml 架构和数据库的表之间定义映射，可以创建持久性数据的"xml 视图"。可以使用 xml 批量负载来填充使用 xml 视图的基础表。您可以查询使用 xpath 1.0 的 xml 视图；该查询将被转换为针对表的 sql 查询。与此类似，更新也会被传递到这些表。

　　在以下情况下，此技术很有用：

　　• 您希望拥有以 xml 为中心的编程模型，该模型使用现有关系数据上的 xml 视图。

　　• 您的 xml 数据具有架构 (xsd, xdr)，它可能由外部合作伙伴提供。

　　• 数据的顺序不重要，或者您的可查询数据不是递归的，或者预先已经知道最大递归深度。

　　• 您希望通过使用 xpath 1.0 的 xml 视图来查询和修改数据。

　　• 您希望批量加载 xml 数据，并将其分解到使用 xml 视图的基础表中。

　　这方面的例子包括以 xml 形式公开以便用于数据交换和 web 服务的关系数据，以及具有固定架构的 xml 数据。有关详细信息，请参阅 sqlxml 开发人员中心。

　　示例：使用带有批注的 xml 架构 (axsd) 对数据进行建模

　　假设您现有一些希望以 xml 形式进行操作的关系数据（例如，客户、订单和行项目）。请使用 axsd 在关系数据上定义 xml 视图。通过 xml 视图，可以将 xml 数据批量加载到表中，以及使用 xml 视图查询和更新关系数据。如果您需要在自己的 sql 应用程序持续工作时与其他应用程序中的 xml 标记交换数据，则该模式很有用。

　　混合模型

　　很多时候，适合将关系数据和 xml 数据类型列结合起来进行数据建模。可以将 xml 数据中的某些值存储在关系列中，而将其余或全部 xml 值存储在 xml 列中。这可能会产生更好的性能（例如，可以完全控制在关系列上创建的索引）和锁定特性。然而，这需要您承担更多的责任来管理数据存储。

　　要存储在关系列中的值取决于您的工作负荷。例如，如果您基于路径表达式 /customer/@custid 检索全部 xml 值，则通过将 custid 属性的值提升到关系列中以及将其编入索引，可能产生更高的查询性能。另一方面，如果您的 xml 数据被广泛且非冗余地分解到关系列中，则重新组合的成本可能很大。

　　对于高度结构化的 xml 数据（例如，表的内容已经转换到 xml），可以将所有值映射到关系列（可能使用 xml 视图技术）。