MSSQL教程之在SQL Server 2005顶用XQuery分化XML数...

因此我们看到，这些信息足够让我们对单个操作实现“逆操作”。<p>　　本文会商SQLServer2005的新功效，它同意你将XML数据分化到干系格局中，而不用耗用太多内存。我们起首懂得一下XQuery和它在SQLServer2005中为开辟者供应的功效。　　XQuery先容
　　XQuery，也称作XMLQuery，是一种查询XML数据的言语，同意你提取所需的节点和元素。它由W3C界说，可用于明天的年夜多半支流数据库引擎中，如Oracle、DB2和SQLServer。
　　SQLServer2005XQuery函数
　　上面的四个函数是SQLServer2005中的XQuery函数。（注重，XML、XQuery语句和上面的函数都辨别巨细写。比方，SQL编译器承受XML数据中的.exist，但回绝.EXIST或.Exist。）xml.exist
　　这个办法依据一个XML节点上的搜刮表达式前往一个布尔值。比方，列表A中XML代码片断中的语句将前往1（真）：SELECT@x.exist(/christmaslist/person[@gift="socks"])
　　这个语句前往0（假）：SELECT@x.exist(/christmaslist/zach)
　　因为“Socks”一词被封套，这个语句将前往0（假）。SELECT@x.exist(/christmaslist/person[@gift="socks"])
xml.value
　　这个办法承受一个XQuery语句并前往一个独自值。利用列表A中一样的XML代码片断，不成以利用VALUE函数天生“betty”值，以下所示：SELECT@x.value(/christmaslist[1]/person[1]/@name,VARCHAR(20))
　　而XQuery天生“zach”值。SELECT@x.value(/christmaslist[1]/person[2]/@name,VARCHAR(20))
xml.query
　　这个办法承受一个XQuery并前往一个XML数据范例的实例。能够按必要将这些查询复杂或庞大化，上面是一个复杂的例子：SELECT@x.query(/christmaslist/person)
　　它前往XML文件：<personname="betty"gift="camera"/>
<personname="zach"gift="elmodoll"/>
<personname="brad"gift="socks"/>
xml.nodes
　　在你必要将一个XML数据范例变量中的数据分化到干系数据中时，这个办法非常有效。这个办法承受一个XQuery语句作为参数，并前往一个包括XML变量逻辑标量数据的行集。列表B中的查询使用下面界说的XML变量，并将数据分化到一个了局会合，它显现在XML变量中界说的人物姓名。
　　修正OPENXML存储历程
　　如今我来讲明怎样修正上周的OPENXML存储历程，使其能够使用XQuery功效。起首，我往XML变量中加载一些数据。如列表C所示。我们能够创建一个承受XML参数的历程，再使用XQuery函数把XML文件中的数据拔出一个表中，而不用使用OPENXML。如列表D所示。
　　最后在数据库中使用XML仿佛有些难于处置，还要花一些工夫习气利用XQuery和Xpath查询。可是，经由一段工夫的进修今后，你就会发明在数据库中使用XML数据相称有用。
　　比方，在上述存储过程当中使用XML数据，你只需挪用一次数据库，而不用像典范存储历程编程那样挪用N次数据库。这两者仿佛区分不年夜，但对一个忙碌的体系而言，使用XML数据会有很年夜好处。并且，使用XQuery而非OPENXML还会明显进步功能，对小型XML文件更是云云。
EXAMPLE存储引擎是一个不做任何事情的存根引擎。它的目的是作为MySQL源代码中的一个例子，用来演示如何开始编写一个新存储引擎。同样，它的主要兴趣是对开发者。EXAMPLE存储引擎不支持编索引。

作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！

外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。

一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。）

可能有的朋友会抱怨集成的orderby，其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率，可以为orderby的字段建立聚集索引，查询计划会忽略orderby操作（因为本来就是排序的嘛）。

多加的系统视图和实时系统信息这些东西对DBA挑优非常有帮助，但是感觉粒度还是不太细。

原来公司用过MYSQL自己也只是建个表写个SQL

在select语句中可以使用groupby子句将行划分成较小的组，然后，使用聚组函数返回每一个组的汇总信息，另外，可以使用having子句限制返回的结果集。

现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层.