MicrosoftSQLServer的ML最佳实施策略.docx

MicrosoftSQLServer的ML最佳实施策略.docx

《MicrosoftSQLServer的ML最佳实施策略.docx》由会员分享，可在线阅读，更多相关《MicrosoftSQLServer的ML最佳实施策略.docx（22页珍藏版）》请在冰豆网上搜索。

MicrosoftSQLServer的ML最佳实施策略

TingBaowasrevisedonJanuary6,20021

MicrosoftSQLServer的ML最佳实施策略

MicrosoftSQLServer2005的XML最佳实施策略

发布日期：

7/5/2004|更新日期：

7/5/2004

作者：

ShankarPal、VisheshParikh、VasiliZolotov、LeoGiakoumakis、MichaelRys

MicrosoftCorporation

适用于：

MicrosoftSQLServer

摘要：

了解SQLServer2005中的XML数据建模和使用准则，并观察一些说明性的示例。

简介

MicrosoftSQLServer2005为XML数据处理提供了广泛的支持。

XML值可以自然地存储在XML数据类型列中，而后者可以根据XML架构集合进行类型化，或者保持非类型化。

可以将XML列编入索引。

而且，使用XQuery和XMLDML（为进行数据修改而进行的扩展）可以支持细粒度的数据操作。

SQLServer2000和SQLXMLWebRelease提供了强大的XML数据管理功能。

这些功能致力于关系数据和XML数据之间的映射。

可以使用带有批注的XSD（AXSD）来定义关系数据的XML视图，以便提供以XML为中心的方法，该方法支持XML数据的批量数据加载、查询和更新功能。

Transact-SQL扩展提供了以SQL为中心的方法，以便将关系查询结果映射到XML（使用FORXML），以及从XML生成关系视图（使用OpenXML）。

这些支持已在SQLServer2005中得到了扩展。

结合新增的原生XML支持，SQLServer2005提供了一种强大的平台，以便针对半结构化和非结构化的数据管理开发功能丰富的应用程序。

本文提供了SQLServer2005中的XML数据建模和使用准则。

它包含以下两个主题：

数据建模

XML数据可用多种方式存储在SQLServer2005中，例如，使用原生XML数据类型和分散到表中的XML。

本主题提供了做出适当的选择以便对XML数据进行建模的准则。

同时，还讨论了将XML数据编入索引、属性提升和XML实例的类型化。

用法

本主题讨论了与用法相关的主题（如将XML数据加载到服务器以及查询编译中的类型推理），解释和区分了密切相关的功能，并推荐了这些功能的适当使用。

文中通过示例阐述了各种概念。

为了最大限度地领会本文的内容，您应该对SQLServer环境中的XML功能有一个基本的了解。

请参阅。

数据建模

本节概述了使用SQLServer2005中的XML的理由，提供了在原生XML存储和XML视图技术之间进行选择的准则，并且提供了数据建模建议。

关系或XML数据模型

如果您的数据是高度结构化的，具有已知的架构，则关系模型可能对于数据存储最为有效。

MicrosoftSQLServer提供了您可能需要的必要功能和工具。

另一方面，如果结构是灵活的（半结构化和非结构化）或未知的，则必须适当地考虑如何对此类数据进行建模。

如果您需要独立于平台的模型，以便确保使用结构化和语义标记的数据的可移植性，则XML是一种不错的选择。

而且，如果满足下列某些属性，则它还是一种适当的选择：

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

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

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

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

如果上述任一条件都不满足，则您应该使用关系数据模型。

例如，如果您的数据是XML格式，但您的应用程序很少使用数据库来存储和检索数据，则[n]varchar（max）列就能满足您的全部需要。

在XML列中存储数据可以带来其他好处-引擎将检查数据格式规范或者有效，并且支持对XML数据进行细粒度的查询和更新。

在SQLServer2005中存储XML数据的理由

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

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

您希望以高效的方式和事务处理方式来共享、查询和修改XML数据。

细粒度的数据访问对于您的应用程序而言很重要。

例如，您可能需要提取XML文档内部的某些节，或者您可能需要插入一个新节而不是替换整个文档。

您具有关系数据和SQL应用程序，您希望在应用程序内部的关系数据和XML数据之间进行互操作。

对于跨域应用程序，您需要有关查询和数据修改的语言支持。

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

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

您希望对XML数据进行SOAP、和OLEDB访问。

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

XML存储选项

SQLServer2005中的XML的存储选项如下所示：

本机存储采用XML数据类型：

用能够保留数据的XML内容（如容器层次结构、文档顺序、元素和属性值等等）的内部表示形式存储数据。

具体说来，就是保留XML数据的信息集内容（有关信息集的详细信息，请参阅）。

它可能不是文本XML的精确副本，因为未保留以下信息：

无关紧要的空格、属性顺序、命名空间前缀和XML声明。

对于类型化的XML数据类型（即绑定到XML架构的XML数据类型）而言，负责向信息集添加类型信息的后架构验证信息集（PostSchemaValidationInfoset,PSVI）以内部表示形式编码。

这会显着提高分析速度。

（有关详细信息，请参阅W3CXML架构规范，网址为和。

）

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的XML视图；该查询将被转换为针对表的SQL查询。

与此类似，更新也会被传递到这些表。

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

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

您的XML数据具有架构（XSD,XDR），它可能由外部合作伙伴提供。

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

您希望通过使用XPath的XML视图来查询和修改数据。

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

这方面的例子包括以XML形式公开以便用于数据交换和Web服务的关系数据，以及具有固定架构的XML数据。

有关详细信息，请参阅。

示例：

使用带有批注的XML架构（AXSD）对数据进行建模

假设您现有一些希望以XML形式进行操作的关系数据（例如，客户、订单和行项目）。

请使用AXSD在关系数据上定义XML视图。

通过XML视图，可以将XML数据批量加载到表中，以及使用XML视图查询和更新关系数据。

如果您需要在自己的SQL应用程序持续工作时与其他应用程序中的XML标记交换数据，则该模式很有用。

混合模型

很多时候，适合将关系数据和XML数据类型列结合起来进行数据建模。

可以将XML数据中的某些值存储在关系列中，而将其余或全部XML值存储在XML列中。

这可能会产生更好的性能（例如，可以完全控制在关系列上创建的索引）和锁定特性。

然而，这需要您承担更多的责任来管理数据存储。

要存储在关系列中的值取决于您的工作负荷。

例如，如果您基于路径表达式/Customer/@CustId检索全部XML值，则通过将CustId属性的值提升到关系列中以及将其编入索引，可能产生更高的查询性能。

另一方面，如果您的XML数据被广泛且非冗余地分解到关系列中，则重新组合的成本可能很大。

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

使用XML数据类型进行数据建模

本节讨论有关原生XML存储的数据建模主题。

这些主题包括将XML数据编入索引、属性提升和类型化XML数据类型。

相同或不同的表

XML数据类型列可以在包含其他关系列的表中创建，也可以在与主表之间具有外键关系的独立表中创建。

在满足下列某个条件时，请在同一个表中创建XML数据类型列：

您的应用程序在XML列上执行数据检索，并且不需要XML列上的XML索引。

或者

您需要在XML数据类型列上生成XML索引，并且主表的主键与其聚集键相同。

有关详细信息，请参阅将XML数据类型列编入索引一节。

在满足下列条件时，请在单独的表中创建XML数据类型列：

您需要在XML数据类型列上生成XML索引，但主表的主键与其聚集键不同，或者主表不具有主键，或者主表是一个堆（也就是说，没有聚集键）。

如果主表已经存在，则这可能是真的。

您不希望表扫描由于表中存在XML列（无论它是存储在行中还是存储在行外，都会占用空间）而降低速度。

XML数据的粒度

XML列中存储的XML数据的粒度对于锁定和更新特性而言至关重要。

SQLServer对XML和非XML数据采用了相同的锁定机制。

因此，行级锁定会导致相应行中的所有XML实例被锁定。

当粒度比较大时，锁定大型XML实例以便进行更新会导致多用户场合下的吞吐量下降。

另一方面，严重的分解会丢失对象封装并提高重新组合成本。

对XML实例进行更新会将现有实例替换为更新后的实例，即使只修改单个属性的值。

XML数据粒度越大，更新成本就越高。

较小的XML实例会产生较高的更新性能。

对于良好的设计而言，重要的是保持数据建模需要与锁定和更新特性之间的平衡。

非类型化、类型化和受约束的XML数据类型

SQLServer2005XML数据类型实现了ISOSQL-2003标准XML数据类型。

因此，它可以在非类型化XML列中存储格式规范的XML文档以及带有文本节点和任意数量顶级元素的所谓的XML内容片段。

系统将检查数据的格式是否规范，不要求将列绑定到XML架构，并且拒绝在扩展意义上格式不规范的数据。

对于非类型化XML变量和参数，也是如此。

如果您具有描述XML数据的XML架构，则可以将这些架构与XML列相关联，以便产生类型化XML。

XML架构用于对数据进行有效性验证，在查询和数据修改语句编译过程中执行比非类型化XML更准确的类型检查，以及优化存储和查询处理。

在下列条件下，请使用非类型化XML数据类型：

您没有对应于XML数据的架构

您拥有架构，但不希望服务器对数据进行有效性验证。

当应用程序在服务器中存储数据之前执行客户端验证时，或者暂时存储根据架构无效的XML数据时，或者使用在服务器中不受支持的架构组件（例如key/keyref）时，有时会出现这种情况。

在下列条件下，请使用类型化XML数据类型：

您拥有对应于XML数据的架构，并且希望服务器按照XML架构对XML数据进行有效性验证。

您希望充分利用基于类型信息的存储和查询优化。

您希望在查询的编译过程中更充分地利用类型信息。

类型化XML列、参数和变量可以存储XML文档或内容-您在声明时必须将它们指定为标志（分别指定为DOCUMENT或CONTENT）。

而且，您必须提供XML架构集合。

如果每个XML实例恰好有一个顶级元素，请指定DOCUMENT；否则，请使用CONTENT。

查询编译器在查询编译过程的类型检查中使用DOCUMENT标记来推理唯一的顶级元素。

除了将XML列类型化以外，您还可以在类型化或非类型化XML数据类型列上使用关系（列或行）约束。

在下列条件下，请使用约束：

无法在XML架构中表示业务规则。

例如，花店的送货地址必须在其营业地点周围50英里范围之内，这可以编写为XML列上的约束。

该约束可能涉及到XML数据类型方法。

您的约束涉及到表中的其他XML列或非XML列。

这方面的一个例子是：

强制XML实例中存在的CustomerID（/Customer/@CustId）与关系CustomerID列中的值匹配。

文档类型定义（DTD）

XML数据类型列、变量和参数可以使用XML架构而不是DTD加以类型化。

然而，对于非类型化和类型化XML，都可以使用内联DTD来提供默认值，以便将实体引用替换为它们的扩展形式。

您可以使用第三方工具将DTD转化为XML架构文档，并且将XML架构加载到数据库中。

将XML数据类型列编入索引

可以在XML数据类型列上创建XML索引。

这会将该列中XML实例上的所有标记、值和路径编入索引，从而提高查询性能。

在下列条件下，您的应用程序可能受益于XML索引：

对XML列进行查询在您的工作负荷中很常见。

必须考虑数据修改过程中的XML索引维护成本。

XML值相对较大，而检索的部分相对较小。

生成索引可以避免在运行时分析全部数据，并且因为受益于索引查找而提高查询处理的性能。

XML列上的第一个索引是"主XML索引"。

通过该索引，可以在XML列上创建三种类型的辅助XML索引，从而提高常见种类的查询的速度，如下节所述。

主XML索引

这会将XML列中的XML实例内部的所有标记、值和路径编入索引。

基表（即包含XML列的表）必须在该表的主键上具有聚集索引；主键用于将索引行与基表中的行相关联。

从XML列中检索完整的XML实例（例如SELECT*）。

查询使用主XML索引，并返回标量值或使用索引本身的XML子树。

示例：

创建主XML索引

在我们的多数示例中，都使用带有非类型化XML列的表T（pkINTPRIMARYKEY,xColXML），这些示例都可以简单地扩展为类型化XML的形式（有关使用类型化XML的信息，请参阅SQLServer2005联机图书）。

为了便于说明，将针对如下所示的XML数据实例描述查询：

Michael

Howard

David

LeBlanc

下面的语句在表T的XML列xCol上创建了名为idx_xCol的XML索引：

CREATEPRIMARYXMLINDEXidx_xColonT（xCol）

辅助XML索引

在创建主XML索引之后，您可能希望创建辅助XML索引来提高工作负荷中的不同种类查询的速度。

三种类型的辅助XML索引-PATH、PROPERTY和VALUE分别为基于路径的查询、自定义属性管理场合和基于值的查询提供帮助。

PATH索引在列中的所有XML实例上，按照文档顺序生成各个XML节点的（path,value）对的B+树。

PROPERTY索引创建各个XML实例中（PK,path,value）对的聚集B+树，其中PK是基表的主键。

最后，VALUE索引在XML列中的所有XML实例中，按照文档顺序创建各个节点的（value,path）对的B+树。

以下是创建上述一个或多个索引的一些准则：

如果工作负荷大量使用XML列中的路径表达式，则PATH辅助XML索引可能会加快工作负荷的处理速度。

最常见的例子是在T-SQL的WHERE子句中对XML列使用exist（）方法。

如果您的工作负荷从单独的使用路径表达式的XML实例中检索多个值，则将各个XML实例中的路径聚集到PROPERTY索引中可能会很有用。

这种情况通常出现在属性包场合中，此时对象的属性被获取并且其主键值已知。

如果您的工作负荷涉及到查询XML实例中的值，而不知道包含这些值的元素或属性名称，则您可能需要创建VALUE索引。

这通常发生在子代轴查找中，例如

"custom"）]'）=1

CONTAINS（）方法使用全文索引，将文档中任何地方包含单词"custom"的XML值组合为一个子集。

exist（）子句确保单词"custom"出现在书名中。

使用CONTAINS（）和XQuerycontains（）的全文搜索具有不同的语义。

后者是子字符串匹配，而前者则是使用单词衍生的标记匹配。

因此，如果要搜索标题中的字符串"run"，则"run"、"runs"和"running"都将匹配，因为全文CONTAINS（）和Xquerycontains（）都满足。

然而，上述查询不匹配标题中的单词"customizable"。

（全文CONTAINS（）失败，而Xquerycontains（）被满足）。

通常，对于纯粹的子字符串匹配，应该删除全文CONTAINS（）子句。

而且，全文搜索采用单词衍生，而XQuerycontains（）是一种字面匹配。

这一区别将在下一个示例中阐述。

示例：

使用单词衍生对XML值进行全文搜索

通常情况下，不能排除示例：

将全文搜索与XML查询结合起来中的XQuerycontains（）检查。

请考虑查询：

SELECT*

FROMT

WHERECONTAINS（xCol,'run'）

因为使用单词衍生，所以文档中的单词"ran"匹配搜索条件。

而且，使用XQuery时不会检查搜索上下文。

在使用被全文索引的AXSD将XML分