场景

每个用户，有多个分组
每个分组在页面展示，而且是有顺序的，这个顺序是由用户决定

以下是关于多种情况下的库表设计思路：

情景一：如果每改一次，就要实时修改库，而且用户可以任意修改顺序，比如5个分组，由54321改为51432

方案1：

用户表，用一个字段存分组表的顺序，比如（1分组Id，2分组Id，3分组Id）
分组表
每次用户修改顺序，只改用户表的这个字段。
查询的时候查出该用户所有分组，按照这个字段排序输出到前端。

方案2：分组表，每个分组加一个权重字段

每次用户修改顺序，对应修改所有分组的这个权重字段（有事务）
查询按照这个权重字段排序即可

方案3：链表思想，每个分组都有一个值，还存有上一个值和下一个值，比如5个分组12345

那么1分组存值1，上一个值null，下一个值2
那么2分组存值2，上一个值1，下一个值3
那么3分组存值3，上一个值2，下一个值4
那么4分组存值4，上一个值3，下一个值5
那么5分组存值5，上一个值4，下一个值null

这时如果要把顺序12345改成14325，只需要
1分组存值1，上一个值null，下一个值2
那么4分组存值4，上一个权重值1，下一个值3
那么3分组存值3，上一个值4，下一个值2
那么2分组存值4，上一个值3，下一个值5
那么5分组存值5，上一个值4，下一个值null

情景一总结：

方案1，要借助用户表来存储分组顺序，而这个属于业务字段，存在用户表中不合适
方案2，有事务，必须多个分组的修改同时成功
方案3，多了3个字段，而且和链表一样，增删改快，查询慢。适合部分小的场景

情景二：如果每改一次，就要实时修改库，但用户只能上下修改，具体参考支付宝设置中的支付顺序的修改

方案4：比如有5个组权重值分别为12345

由于每个分组每次修改只能和相邻的分组互换权重值，所以这个比较好实现
每次都做一个事务的修改，事务中就只有相邻的两个分组交换权重值。

情景三：如果专门有个页面，供用户修改，最终保存，这种最好实现，也最low，用户体验不好，具体可参考讯飞输入法常用语的分组设置模式

方案5：每次前台改完，都有新的顺序，比如初5个组的初始权重是A-1,B-2,C-3,D-4,E-5

改后可能完全乱了，比如改后可能是A-2,B-3,C-1,D-5,E-4.
那么这种就只能在一个事务中分别修改5个分组的权重了。

总结

以上方案，如果非要改进，还可以加一层缓存，尤其是情景一，当然，任何大一点的项目，数据库前面都最好有缓存挡着。
而且针对情景一和情景二，还可以考虑用阻塞队列的思路，考虑到用户多次修改后，总会停下来，比如设置3秒，3秒内取队列的最后一个修改的顺序，
这时候相当于用阻塞队列将情景一和情景二强行转换成情景三的实现方式，而且用户体验还比单纯的情景三要好