关于排序的算法問題。

乱码

原帖由 混不到坑的萝卜 于 2011-8-9 13:08 发表
我想了一下，为什么不能这么搞呢？一个Update互换两条记录的SortOrder栏：

CREATE TABLE [dbo].[AAA](
        [SortOrder]  NOT NULL,
        [Name] [nvarchar](max) NULL,
        [Description] [nvarchar](max) NULL
)
go

insert into A ...

我同意這個思路。

如果把logic放在client side，最後persist到db那邊就最好了

混不到坑的萝卜

原帖由 乱码 于 2011-8-9 13:16 发表
如果把logic放在client side，最後persist到db那邊就最好了

是的，这样的话效率更高。

鱼羊鲜

这还是两条update啊，where效率不高，直接用索引的id做条件比这快多了

原帖由 混不到坑的萝卜 于 2011-8-9 13:08 发表
我想了一下，为什么不能这么搞呢？一个Update互换两条记录的SortOrder栏：

CREATE TABLE [dbo].[AAA](
        [SortOrder]  NOT NULL,
        [Name] [nvarchar](max) NULL,
        [Description] [nvarchar](max) NULL
)
go

insert into A ...

dalaohu

多谢大家的input啦。

看来思路基本上就差不多的。

我大致看了一下，基本决定就是全部client做， 取相邻2个Order的中间值-就像jungle 说的。来计算出当前row的新Order。

然后DB方面就特简单的只 update 当前一个row的order。

jungle

原帖由 dalaohu 于 2011-8-9 14:39 发表
多谢大家的input啦。

看来思路基本上就差不多的。

我大致看了一下，基本决定就是全部client做， 取相邻2个Order的中间值-就像jungle 说的。来计算出当前row的新Order。

然后DB方面就特简单的只 update 当前一个row的order。

老兄，你这个算法，用户只需 UP BBB, 再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，再UP CCC，再UP BBB，

然后你就出问题了

netstat

不用对效率这样的追求吧，又不是在中国，写个网页每秒点击上w次。

dalaohu

会吗？ 他们只是无限的接近0， 但用于不会到0

jungle

原帖由 dalaohu 于 2011-8-9 14:54 发表
会吗？ 他们只是无限的接近0， 但用于不会到0

老兄你认为float的精度是无限的嘛？可以区分两个无限接近的float value的差值？

典

还有，如果同一时段
用户A 点 up CCC
用户B 点 up BBB
用户A 点 up DDD
用户B 点 up DDD
...
结果也会很好玩吧

dalaohu

sql float default 有53 bits， 足够了。

dalaohu

这个是普遍线程问题，data layer 有framework handle的。

每个用户是sort自己的数据，碰不到别人的。 说到底这个sortnum也不是critical的东西。即使2个碰巧一样了，也没大碍，再点一下好了。

[ 本帖最后由 dalaohu 于 2011-8-9 15:16 编辑 ]

鱼羊鲜

都是一大串小数的时候，那效率提高了么

[ 本帖最后由 鱼羊鲜 于 2011-8-9 15:18 编辑 ]

dalaohu

要看具体user case的，这个实际情况是，admin创建一个新 project，然后往里添加items。
然后就是sort 几下，一旦publish to live 了，sorting order基本就根本不会再变了。

所以我吧基数定大点，基本上一个小数点都不会出现的。

xxmplus

既然如此，这里根本就不是性能瓶颈，保持逻辑简单才是王道

jungle

呵呵，刚才比较无聊，写了几句SQL 来测试LZ这种算法究竟能扛住多少次 UP BBB, UP CCC

测试环境 SQL SERVER 2008 R2

先执行以下SQL:
Create Table TestSort (Value varchar(10), SortNumber float)
Insert into TestSort values ('AAA',1)
Insert into TestSort values ('BBB',2)
Insert into TestSort values ('CCC',3)

然后反复执行以下SQL:
Declare @maxSortNumber float
Declare @avgPrevSortNumbers float

Select @maxSortNumber = max(SortNumber) from TestSort
Select @avgPrevSortNumbers= AVG(SortNumber) from TestSort where SortNumber<@maxSortNumber

Update TestSort set SortNumber = @avgPrevSortNumbers where SortNumber=@maxSortNumber
Select * from TestSort order by SortNumber

果然证明了SQL SERVER的FLOAT是53 BITS～～第2段 SQL 执行54次之后完蛋

混不到坑的萝卜

原帖由 dalaohu 于 2011-8-9 14:54 发表
会吗？ 他们只是无限的接近0， 但用于不会到0

依你这个逻辑，兔子是永远追不上乌龟的……

你那个既然只是Admin用的，考虑太多纯属浪费，直接用类似我写的那个就够了。性能都不是问题。

兼答鱼羊鲜：“这还是两条update啊，where效率不高，直接用索引的id做条件比这快多了”
你完全可以在SortOrder column上建一个clustered index。如此一来效率就和两条Update相似，但程序的可维护性会好点（因为不需要知道两条记录的ID）？

dalaohu

53次对除就完蛋了？ 这个少了点啊。。。

53次有多少位小数点了？

dalaohu

看样子只剩萝卜兄的 2次update，order 对调了。