MSSQL编程：SQL Story摘录（九）――――不等连接

根据Ambrose所说，Sakila来自一种叫SiSwati的斯威士兰方言，也是在Ambrose的家乡乌干达附近的坦桑尼亚的Arusha的一个小镇的名字。
不等连接

一般来讲，SQL言语举行的都是无序操纵。想要举行有序的处置，好比对照一个序列的前后项，必需要利用游标。可是，在有些场所下，可接纳另外一种办法，不必游标，一样能处置有序的信息，这就是不等连接。先看上面一个例子

前一阵，CSDN网友BuildIt来信，和我会商了如许的成绩：以下表HISTORY

CREATETABLE[HISTORY](

[TheDate][datetime]NULL,

[Quantity][int]NULL

)ON[PRIMARY]

中存储的是一系列的汗青数据，比方：

INSERTHISTORYVALUES(2002-01-0100:00:00.0,11)

GO

INSERTHISTORYVALUES(2002-01-0200:00:00.0,34)

GO

INSERTHISTORYVALUES(2002-01-0300:00:00.0,27)

GO

INSERTHISTORYVALUES(2002-01-0400:00:00.0,43)

GO

如今，我们要查询自肇端日期至每个日期的总量。也就是说，显现如许一个了局集：

TheDateQuantityq_sum

2002-01-0100:00:00.01111

2002-01-0200:00:00.03445

2002-01-0300:00:00.02772

2002-01-0400:00:00.043115

直不雅下去讲，我们能够在SELECT*FROMHISTORYORDERBYTheDate上建一个游标，从第一条入手下手，每条，加一次。那换个设法呢？假如我们创建如许一个了局集，让每个日刻日，都对应它当天的数目及一切在它之前的数目纪录。那末我们就能够按这个日期分组，对数目举行乞降。很明显，一个不等查询就如许构成了。我最后的写法有毛病，以下是经BuildIt修正后终极的语句

selectl.TheDate,

l.quantity,

sum(r.quantity)asq_sum

fromHISTORYl

joinHISTORYr

onl.TheDate>=r.TheDate

groupbyl.TheDate,l.quantity

orderbyl.TheDate

不等连接自己就不是逐一对应，它的对应干系温柔序有着亲切的干系。这也就是我们可以拿它来举行有序操纵的缘故原由。再给一个很天然的例子：

SELECTL.I,SUM(R.I)

FROMNL

JOINNR

ONL.I>=R.I

GROUPBYL.I

表N只要一个整型列I，保留天然数列。以是，没甚么奥秘，这就是求天然数列的和。这里SUM(R.I)暗示天然数列N从零至I的累加和，比后面的谁人成绩还要复杂。不外明显这不是不等连接发扬能力的中央，由于它会构成一个伟大的三角形数据集，就像上面如许

11

21

22

31

32

33

...

当我对十六位整型的列表实行这个查询时，我的AthlonXP1700+/256MDDR的呆板足足运转了近三非常钟，当我写下如今这段笔墨时，它前往了一个数据溢堕落误。明显，关于这个查询，即便是十六位整数的列表，也太年夜了。我的倡议是，仅当了局集没法用公式表达时，利用不等连接。像这个累加，我们早已有了成熟的公式，何须再让盘算机傻算呢？用上面这个语句

SELECTI,((1+I)*I)/2

FROMN

比拟老厚道实地累加，速率奇快。发明数据溢出时，连一秒钟都不到，可这台盘算机就是想不到用这个办法，唉……

传说数学界一代宗师高斯小学的时分，他先生考过他这个成绩。以是几近一切的中国小先生，都被先生用这道题熬煎过。仿佛先生们的目标就在于告知我们，我们的智商比不上高斯。可我压根就没想和人家比啊……

上年夜学时，教我们第一本《数学剖析》的范先令先生说盘算机是傻子，我事先只是以为好玩罢了，明天算是见地了，看来在归结总结的才能方面，盘算机也就是我小学时的程度，永久也赶不上高斯上小学那会儿了。

不外，这类器材用于公式难以表达的中央，仍是成心义的。好比我的一个伴侣用不等连接写过一个素数筛子，很风趣。它虽然说不会比我们用历程化的代码写出来的程序效力更高，但却能把筛法基本的精要表达的清分明楚，大概今后我们研讨数论，会用的上这类SQL作风的暗示法呢。这位伴侣教了我良多盘算机方面的常识，出于对他的尊敬，我不会抄写他的代码。不外这个语句自己其实不庞大，信任伴侣们想到用连接查询后，都必定写得出来，人人有乐趣的话，本人无妨尝尝。用它还能够完成别的的一些数列，今后我们再会商几个。

不等连接另有一个用法，能够用它天生一个序号列，好比

SELECTCOUNT(L.AFIELD)ASID,

L.AFIELD

FROMMYTABLEL

JIONMYTABLER

ONL.AFIELD>R.AFIELD

GROUPBYL.AFIELD

AFIELD字段能够是字符串、日期，固然也能够是数值，归正可排序就行。这器材有点奇技淫巧的滋味，数据量太年夜，就欠好玩了，一样平常仍是用物理行号的好，虽然说不是SQL尺度，但有用啊。这个例子我在MCDBA的温习题中见过（听说这道题考过），不外我的那位伴侣本人就做出来过，人人大概也有自力完成过这一办法的吧。

不等查询的有序操纵才能，明显来自连接字段的可排序和互同性，以是，最好不要在有反复值的字段上做不等连接（现实上，最好不要在有反复值的字段上做任何连接，除非你十分一定你在干甚么）。等值连接呈现数据爆炸就够可骇的了，不等连接如果玩爆了……嘿嘿嘿……

想像一个等值连接中有一对反复值，大概呈现两对反复了局。不外如果不等连接，就和反复的地位有关了。由于这是一个三角形，以是呈现在最下面还好，如果呈现在这个三角形的下部……

不等连接查询，明显是一个无力的工具，但它也是招来贫苦的快速体例之一。有几个倡议，是我的履历：
假如连接会天生很年夜的“三角形”，就不要用，尝尝子查询或哪怕游标；

天生的了局集相对原表越小越好，尽量地把无用的数据先过滤失落；

用不等连接举行数列盘算会表达的很分明（由于长短历程化的），但一般在效力上它没有甚么上风，以是，平常玩玩能够，真用的话最好先思索好；

另有就是不等连接不要容易用在多重连接中，不然大概会引发杠杆感化。

祝人人在这个奇妙的天下中游览兴奋！
BDB源自BerkeleyDB，事务型数据库的另一种选择，支持COMMIT和ROLLBACK等其他事务特性

另一个是把SQL语句写到服务器端,就是所谓的SP(存储过程);

不过话说回来了，绝大多数的性能优化准则与对sqlserver存储的结构理解息息相关

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。

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

是要和操作系统进行Socket通讯的场景。否则建议慎重！

理解了存储结构，再阅读下性能优化的章节基本上会对sqlserver有个清晰地认识

记得在最开始使用2k的时候就要用到这个功能，可惜2k没有，现在有了作解决方案的朋友会很高兴吧。