Sql server 的XML最佳实施策略.docx
- 文档编号:30757424
- 上传时间:2023-08-20
- 格式:DOCX
- 页数:30
- 大小:35.56KB
Sql server 的XML最佳实施策略.docx
《Sql server 的XML最佳实施策略.docx》由会员分享,可在线阅读,更多相关《Sql server 的XML最佳实施策略.docx(30页珍藏版)》请在冰豆网上搜索。
Sqlserver的XML最佳实施策略
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功能有一个基本的了解。
请参阅XMLSupportinMicrosoftSQLServer2005。
返回页首
数据建模
本节概述了使用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、ADO.NET和OLEDB访问。
如果不满足上述任一条件,您最好将数据存储为非XML的大型数据类型,如[n]varchar(max)或varbinary(max)。
XML存储选项
SQLServer2005中的XML的存储选项如下所示:
•本机存储采用XML数据类型:
用能够保留数据的XML内容(如容器层次结构、文档顺序、元素和属性值等等)的内部表示形式存储数据。
具体说来,就是保留XML数据的信息集内容(有关信息集的详细信息,请参阅http:
//www.w3.org/TR/xml-infoset)。
它可能不是文本XML的精确副本,因为未保留以下信息:
无关紧要的空格、属性顺序、命名空间前缀和XML声明。
对于类型化的XML数据类型(即绑定到XML架构的XML数据类型)而言,负责向信息集添加类型信息的后架构验证信息集(PostSchemaValidationInfoset,PSVI)以内部表示形式编码。
这会显著提高分析速度。
(有关详细信息,请参阅W3CXML架构规范,网址为http:
//www.w3.org/TR/xmlschema-1和http:
//www.w3.org/TR/xmlschema-2。
)
•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视图的基础表。
您可以查询使用XPath1.0的XML视图;该查询将被转换为针对表的SQL查询。
与此类似,更新也会被传递到这些表。
在以下情况下,此技术很有用:
•您希望拥有以XML为中心的编程模型,该模型使用现有关系数据上的XML视图。
•您的XML数据具有架构(XSD,XDR),它可能由外部合作伙伴提供。
•数据的顺序不重要,或者您的可查询数据不是递归的,或者预先已经知道最大递归深度。
•您希望通过使用XPath1.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视图技术)。
返回页首
使用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列中存储格式规范的XML1.0文档以及带有文本节点和任意数量顶级元素的所谓的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数据实例描述查询:
下面的语句在表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索引。
这通常发生在子代轴查找中,例如//author[last-name="Howard"],其中元素可以出现在层次结构的任意级别上。
这种情况还会发生在"通配符"查询中,例如/book[@*="novel"],其中查询将查找具有某个值为"novel"的属性的元素。
示例:
基于路径的查找
假设下面的查询在您的工作负荷中很常见:
SELECTpk,xCol
FROMT
WHERExCol.exist('/book[@genre="novel"]')=1
路径表达式/book/@genre和值"novel"对应于PATH索引的键字段。
因此,PATH类型的辅助XML索引对于该工作负荷很有用:
CREATEXMLINDEXidx_xCol_PathonT(xCol)
USINGXMLINDEXidx_xColFORPATH
示例:
获取对象的属性
请考虑下面的查询,它从表T的各个行中检索一本书的属性"genre"、"title"和ISBN:
SELECTxCol.value('(/book/@genre)[1]','varchar(50)'),
xCol.value('(/book/title)[1]','varchar(50)'),
xCol.value('(/book/@ISBN)[1]','varchar(50)')
FROMT
在这种情况下,属性索引很有用,其创建方式如下所示:
CREATEXMLINDEXidx_xCol_PropertyonT(xCol)
USINGXMLINDEXidx_xColFORPROPERTY
示例:
基于值的查询
在以下查询中,子代轴或自身轴(//)指定了部分路径,以便基于ISBN
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Sql server 的XML最佳实施策略 XML 最佳 实施 策略