一个distinct问题引发的思考
2013-04-08 22:28
253 查看
一个distinct问题引发的思考
今天被人问到这样一个问题,整理出来给大家也参考一下假设有如下这样一张表格:
![](http://images.cnitblog.com/blog/9072/201304/08203926-47cc2bdaf31e430f9fe1c3b63073b2e9.png)
这里的数据,具有如下的特征:在一个DepartmentId中,可能会有多个Name,反之也是一样。就是说Name和DepartmentId是多对多的关系。
现在想实现这样一个查询:按照DepartmentID排完序之后(第一步),再获取Name列的不重复值(第二步),而且要保留在第一步后的相对顺序。以本例而言,应该返回三个值依次是:ACB
我们首先会想到下面这样一个写法
select distinct name from Sample order by DepartmentId
从语义上说,这是很自然的。但是很可惜,这个语句根本无法执行,错误消息是:
![](http://images.cnitblog.com/blog/9072/201304/08203927-1866f10c3c2642a09a8c168d53653b30.png)
这个错误的意思是,如果使用了DISTINCT(去重复值),则出现在OrderBy后面的字段,必须也出现在SELECT后面,但如果DepartmentID如果也真的出现在SELECT后面,显然是不会有重复值的,所以结果肯定也是不对的。
select distinct name,DepartmentId from Sample order by DepartmentId
![](http://images.cnitblog.com/blog/9072/201304/08203928-e7f36ce0c7e64772b0666d00857f4f96.png)
那么,既然DISINCT 与OrderBy结合起来用会有这个的一个问题,我们是否有可能变通一下,例如下面这样:
SELECT distinct a.Name FROM (select top 100 percent name from Sample order by DepartmentId) a
想比较之前的写法,我们用到了子查询技术。同样从语义上看,仍热是很直观明了的。我想先按照DepartmentId进行排序, 然后再去重复值。但是返回到结果是下面这样的:
![](http://images.cnitblog.com/blog/9072/201304/08203929-28f283f302954accbd03c271483e1fa3.png)
虽然确实去除了重复值,但返回的顺序却是不对的。我们希望是先按照DepartmentId排序之后,然后去除重复值,并且保留排序后的相对顺序。
为什么会出现上面这个结果呢?其实是因为DISTINCT本身是会做排序的,而且这个行为是无法更改的(下图的执行计划中可以看到这一点)。所以其实我们之前做的Order by在这里会失去意义。【实际上,如果观察ADO.NET Entity Framework等ORM工具中生成的类似的一个查询,它会自动丢弃Order by的设置】
![](http://images.cnitblog.com/blog/9072/201304/08203929-3199d4bdb109405cb1e1757decec31fd.png)
那么,这样的情况下,是不是就不可能实现需求了呢?虽然说,这个需求并不多见,绝大部分时候,DISTINCT作为最后一个操作,做一次排序是合乎情理的。
我是这样考虑到,既然DISTINCT的这个行为是内置的,那么是否可以绕过这个操作呢?最终我用的一个解决方案是:我能不能把每个Name都编上一个编号,例如有两个A的话,第一个A我为它编号为1,第二个编号为2,以此类推。然后,查询的时候,我先排序,然后筛选那些编号为1的Name,这样其实也就实现了去重复值了。
SQL Server 2005开始提供了一个ROW_NUMBER的功能,结合这个功能,我实现了下面这样的查询:
select a.Name from (select top 100 percent Name,DepartmentId,ROW_NUMBER() over(partition by name order by departmentid) row from Sample order by DepartmentId) a where a.row=1 order by a.DepartmentId
然后,我得到了下面这样的结果,我推敲下来,这应该是符合了之前提到的这个需求的
![](http://images.cnitblog.com/blog/9072/201304/08203930-9ef21f1afcdd414c9f0419771ce2f69a.png)
相比较而言,这个查询的效率会低一些,这个是可以预见的(可以通过下图看出一点端倪)。但如果需求是硬性的,那么牺牲一些性能也是不奇怪的。当然,我们可以再研究看看是否有更优的一些写法。无论如何,使用内置标准的实现,通常都是相对较快的。
![](http://images.cnitblog.com/blog/9072/201304/08203932-560fa6651ade464c8f8352b5ae4863a5.png)
相关文章推荐
- 一个distinct问题引发的思考
- 面试中的一个小问题引发的思考
- 一个问题引发的思考
- 一个iphone的设置问题引发的思考!
- 一个Java NIO问题引发的思考
- 由一个问题引发的思考
- 一个distinct问题引发的记录
- 2015-11-02-04-一个问题引发的思考
- 细节:一个很SB的问题引发的思考
- 沫沫金::一个小问题引发的大思考
- 一个问题引发的一点思考
- 一个多线程synchronized引发的问题思考
- 一个回车符引发的问题思考
- 一个问题引发的对类成员指针的思考
- WPF 布局心得 一个像素引发的问题和思考
- 一个detect问题引发的一系列思考
- android开发之一个手机重启问题引发的思考
- 一个小问题引发的论证思考
- 一个“粘贴”问题引发的思考
- 一个“粘贴”问题引发的思考