Dear all,

        RT,   有一堆数据，现实给用户时这些数据是可以让用户
自己手动排序的，但是我觉得我现在处理顺序的做法很别扭：

        我在数据库的记录中多加了一列 "Order"， 里面有个整型数值。
但是缺点是，每次调整某个靠前位置时，我都要把数据库中所有记录
的Order修改一遍，我觉得这是个愚蠢的做法。本身目的是修改一条记
录的位置，但是却被迫改变所有记录的数据，这个操作理论上应该是一
个"原子操作"，如果数据量过大的话，会不会存在效率／体验方面的问题？

        我想这种很常见的场景应该有更聪明的方式去处理。  之前私下和一
些从事数据库开发的同学讨论过，但他们说也用的类似我的这个方法，这
让我颇为不解，所以前来讨教。

         
Thanks
B.R
Kermit

On 11-26 15:18, Kermit.Mei wrote:
>Dear all,
>  RT, 有一堆数据，现实给用户时这些数据是可以让用户
>自己手动排序的，但是我觉得我现在处理顺序的做法很别扭：
>  我在数据库的记录中多加了一列 "Order"， 里面有个整型数值。
>但是缺点是，每次调整某个靠前位置时，我都要把数据库中所有记录
>的Order修改一遍，我觉得这是个愚蠢的做法。本身目的是修改一条记
>录的位置，但是却被迫改变所有记录的数据，这个操作理论上应该是一
>个"原子操作"，如果数据量过大的话，会不会存在效率／体验方面的问题？
>  我想这种很常见的场景应该有更聪明的方式去处理。  之前私下和一
>些从事数据库开发的同学讨论过，但他们说也用的类似我的这个方法，这
>让我颇为不解，所以前来讨教。


写的时候麻烦了一些, 但是读的时候这种方式不是很方便么, 直接一个 `order by` 就解决问题.

这种有序的结构也可以像"链表"那样, 在关系数据库中存 ``before / after`` , 这样改和删都很方便, 但是读的时候就麻烦了.

效率问题上, 在实际中这种情况应该不会发生, 因为业务上你要做的是"手动排序", 如果条目过多做不了"手动".

如果说"手动排序"只是一种补充方案, 那这里的 //Order// 可以理解成是一种"权重"的概念, 允许它重复就可以少"改"的麻烦.





--
进出自由才是游戏者的生存之道。

http://zouyesheng.com
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20131126/fa306dd0/attachment.html>

嗯，Order在这里确实就是个权重的概念。
看您的回复，貌似大家确实都是这么用的。

我后面又想了一下解决方案来避免每次修改所有数据：

这个Order权重 存放的不是一个整数，而是一个浮点数，
对于初始化数据，每个数据的间隔都是1，但是移动的时
候，采用叠加小数的权重，比如：
原始数据：
(data1,  1), (data2,  2), (data3,  3), (data4,  4), (data5,  5)
把data2 移动到 4和5之间：
(data1,  1), (data2,  4.1), (data3,  3), (data4,  4), (data5,  5)

如果0.1用完了，就用 0.01，依次类推，这样就永远只需改变 
需要移动的那个item的order值即可。


不过，不是很自信的是，这种方式会不会造成order by在效率
等方面产生问题？

B.R
Kermit

> 在 2013年11月26日，下午4:10，"YS.Zou" <yeshengzou在gmail.com> 写道：
> 
> On 11-26 15:18, Kermit.Mei wrote:
> 
>  Dear all,
>   RT, 有一堆数据，现实给用户时这些数据是可以让用户
>  自己手动排序的，但是我觉得我现在处理顺序的做法很别扭：
>   我在数据库的记录中多加了一列 "Order"， 里面有个整型数值。
>  但是缺点是，每次调整某个靠前位置时，我都要把数据库中所有记录
>  的Order修改一遍，我觉得这是个愚蠢的做法。本身目的是修改一条记
>  录的位置，但是却被迫改变所有记录的数据，这个操作理论上应该是一
>  个"原子操作"，如果数据量过大的话，会不会存在效率／体验方面的问题？
>   我想这种很常见的场景应该有更聪明的方式去处理。  之前私下和一
>  些从事数据库开发的同学讨论过，但他们说也用的类似我的这个方法，这
>  让我颇为不解，所以前来讨教。
> 写的时候麻烦了一些, 但是读的时候这种方式不是很方便么, 直接一个 `order by` 就解决问题.
> 
> 这种有序的结构也可以像"链表"那样, 在关系数据库中存 before / after , 这样改和删都很方便, 但是读的时候就麻烦了.
> 
> 效率问题上, 在实际中这种情况应该不会发生, 因为业务上你要做的是"手动排序", 如果条目过多做不了"手动".
> 
> 如果说"手动排序"只是一种补充方案, 那这里的 Order 可以理解成是一种"权重"的概念, 允许它重复就可以少"改"的麻烦.
> 
> -- 
> 进出自由才是游戏者的生存之道。
> 
> http://zouyesheng.com
> 
> _______________________________________________
> zeuux-universe mailing list
> zeuux-universe在zeuux.org
> http://www.zeuux.org/mailman/listinfo/zeuux-universe
> 
> ZEUUX Project - Free Software, Free Society!
> http://www.zeuux.org
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20131126/0a65c39e/attachment.html>

On 11-26 16:25, Kermit.Mei wrote:
>嗯，Order在这里确实就是个权重的概念。
>看您的回复，貌似大家确实都是这么用的。
>
>我后面又想了一下解决方案来避免每次修改所有数据：
>
>这个Order权重 存放的不是一个整数，而是一个浮点数，
>对于初始化数据，每个数据的间隔都是1，但是移动的时
>候，采用叠加小数的权重，比如：
>原始数据：
>(data1,  1), (data2,  2), (data3,  3), (data4,  4), (data5,  5)
>把data2 移动到 4和5之间：
>(data1,  1), (data2,  4.1), (data3,  3), (data4,  4), (data5,  5)
>
>如果0.1用完了，就用 0.01，依次类推，这样就永远只需改变 
>需要移动的那个item的order值即可。
>
>不过，不是很自信的是，这种方式会不会造成order by在效率
>等方面产生问题？


先不管效率层面的考虑, 在代码实现和执行控制上都是得不偿失的. 浮点数的精度不可能永远满足排序要求的.

之前的移动, 只涉及两条 SQL 语句:

```sql
update xx set `order` = `order` + 1 where `order` > a;
update xx set `order` = a;
```

整个过程是可控的.

而这个小数方案, 随着移动行为的不断发生, 你的数据是一种无法控制的"蔓延"状态.




--
进出自由才是游戏者的生存之道。

http://zouyesheng.com
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20131126/e18c6a28/attachment-0001.html>

> 在 2013年11月26日，下午4:50，"YS.Zou" <yeshengzou在gmail.com> 写道：
> 
> On 11-26 16:25, Kermit.Mei wrote:
> 
>  嗯，Order在这里确实就是个权重的概念。
>  看您的回复，貌似大家确实都是这么用的。
>  
>  我后面又想了一下解决方案来避免每次修改所有数据：
>  
>  这个Order权重 存放的不是一个整数，而是一个浮点数，
>  对于初始化数据，每个数据的间隔都是1，但是移动的时
>  候，采用叠加小数的权重，比如：
>  原始数据：
>  (data1,  1), (data2,  2), (data3,  3), (data4,  4), (data5,  5)
>  把data2 移动到 4和5之间：
>  (data1,  1), (data2,  4.1), (data3,  3), (data4,  4), (data5,  5)
>  
>  如果0.1用完了，就用 0.01，依次类推，这样就永远只需改变 
>  需要移动的那个item的order值即可。
>  
>  不过，不是很自信的是，这种方式会不会造成order by在效率
>  等方面产生问题？
> 先不管效率层面的考虑, 在代码实现和执行控制上都是得不偿失的. 浮点数的精度不可能永远满足排序要求的.
> 

嗯，应该是我想多了。  我是想当检测到浮点越界的时候，再执行一步你下面这个操作
作为补充。 不过代码实现上，如果全部用SQL来写，确实有点儿得不偿失。


> 之前的移动, 只涉及两条 SQL 语句:
> 
>   update xx set `order` = `order` + 1 where `order` > a;
>   update xx set `order` = a;
> 整个过程是可控的.
> 
> 而这个小数方案, 随着移动行为的不断发生, 你的数据是一种无法控制的"蔓延"状态.
> 
> -- 
> 进出自由才是游戏者的生存之道。
> 
> http://zouyesheng.com
> 
-------------- 下一部分 --------------
一个HTML附件被移除...
URL: <http://www.zeuux.org/pipermail/zeuux-universe/attachments/20131126/36dae9cf/attachment.html>