多级邀请数据库设计

[caoyufei]

uid 7 是 1 的 1 级

9 是 7 的 1 级

9 是 1 的 3 级

每个人都是 1 级 也可能是别人的 二级 三级，

最多 7 级

如果查 1 的 7 级全部下线

parents like  '1%'

可要查 7 的 全部下线，感觉就不行了

求数据库设计方案

[clino]

要不把 某个人和他的所有上线的关系都表达出来,比如某个人有 5 级上线,则有 5 条记录,里面包含上下线和中间层级
这样虽然比较冗余,但是你要的查询是可以方便查出来的

[crystom]

关键词：左右值

[czheo]

https://dev.mysql.com/doc/refman/5.7/en/string-functions.html#function_find-in-set

[DKR]

只记录直属关系，多次遍历，查找整个关系链，其他信息单独一个表

[levon]

对，一个 ParentId 就可以

[iscraft]

在自己尚处在想象的一个项目中有这么一个类似的需求 对于这个情况有 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

[yazohu]

关键词: 嵌套集合

[leeg810312]

parents 保存完整的上级路径，查询 7 下级写 parents like '1,7,%'，查询 10 下级写 parents like '1,7,9,10,%'

[dong3580]

id parentid

只记录直属关系

[changwei]

楼主的头像要小心了

[caoyufei]

@changwei 这还好啦，为毛你会关注到头像

[telami]

其实，这是一种典型的 tree 型结构，楼上说了几种方案，parentId 属于邻接表，左右值属于嵌套集，一楼的方案属于闭包表，各有千秋。
过去一年了，不知道楼主选了怎么样的方案？