关系或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视图技术）。