这是一个创建于 2590 天前的主题，其中的信息可能已经有所发展或是发生改变。
uid 7 是 1 的 1 级
9 是 7 的 1 级
9 是 1 的 3 级
每个人都是 1 级 也可能是别人的 二级 三级，
最多 7 级
如果查 1 的 7 级全部下线
parents like '1%'
可要查 7 的 全部下线，感觉就不行了
求数据库设计方案
 |
1
clino 2017-11-09 10:49:32 +08:00
要不把 某个人和他的所有上线的关系都表达出来,比如某个人有 5 级上线,则有 5 条记录,里面包含上下线和中间层级
这样虽然比较冗余,但是你要的查询是可以方便查出来的 |
 |
2
crystom 2017-11-09 10:52:05 +08:00
关键词：左右值
|
 |
3
czheo 2017-11-09 10:53:29 +08:00
|
 |
4
DKR 2017-11-09 11:07:13 +08:00
只记录直属关系，多次遍历，查找整个关系链，其他信息单独一个表
|
 |
5
levon 2017-11-09 11:47:09 +08:00
对，一个 ParentId 就可以
|
 |
6
iscraft 2017-11-09 12:50:18 +08:00
在自己尚处在想象的一个项目中有这么一个类似的需求 对于这个情况有 3 年时间内都在不断迷惑 求解
@crystom 看过 destoon 的 area 表和左右值 数据量小或者数据变动次数不多的时候使用 parent 或者左右值非常合适 最终还是要根据数据的具体情况来看 @czheo find_in_set 是真的好用 这是我在一个小预约程序上添加一个小功能但最终不得不从 sqlite 迁移到 mysql 上得到的教训 但较大数据量效率一般 且仅支持 mysql @DKR 多次遍历存在嵌套循环 用时久消耗大 最后我的意见是 如果不是无限分级 级别总数值小并且有上限的话 就把所有的级数都列在同一张表内 uid l1 l2 l3 l4 l5 l6 l7 1 7 0 9 0 0 0 0 7 9 0 0 0 0 0 0 1 的 1 级是 7,7 的 1 级是 9,1 的 3 级是 9 全部下线 就多用几个 and |
 |
7
yazohu 2017-11-09 13:10:27 +08:00 via Android
关键词: 嵌套集合
|
 |
8
leeg810312 2017-11-09 13:26:51 +08:00 via Android
parents 保存完整的上级路径，查询 7 下级写 parents like '1,7,%'，查询 10 下级写 parents like '1,7,9,10,%'
|
 |
9
dong3580 2017-11-09 13:42:43 +08:00
id parentid
只记录直属关系 |
 |
10
changwei 2017-11-09 14:02:04 +08:00 via Android
楼主的头像要小心了
|
 |
12
telami 2019-06-27 17:55:46 +08:00
其实，这是一种典型的 tree 型结构，楼上说了几种方案，parentId 属于邻接表，左右值属于嵌套集，一楼的方案属于闭包表，各有千秋。
过去一年了，不知道楼主选了怎么样的方案？ |
Select Language