还是关于层次结构表设计的问题

Question

首先是分级的组织结构
集团公司/分公司/部门/组/...
然后是人员，可能同时属于某几个组的管辖要求：
1、能够根据层次表生成树状菜单
2、能够快速获取某个级别或某个级别的指定部门的所有人员该如何设计表才比较合理呢？

Answer 1

1.组织表(组织ID，组织名称,父组织ID)
2.员工组织表(员工ID，组织ID）

Answer 2

数据数据量不大就是父子关系结构了id pid name   
----------- ----------- --------------------  
1 0 食品
2 1 水果
3 1 蔬菜
4 2 香蕉
5 2 苹果
6 3 青菜可以用递归来找相应的父子关系
但是递归总是有性能瓶颈的，数据量偏大的递归就不考虑了
会有一些冗余设计。

Answer 3

你之前有类似的回答了，冗余设计如何设计比较好，递归查找你是指用CTE吧

Answer 4

id pid name
1001 0 食品
1001001 1001 水果
1001002 1001 蔬菜
1001001001 1001002 香蕉
1001001002 1001002 苹果
1001002001 1001002 青菜--比如这样的结构 要查询水果以及他的所有下级SELECT * FROM TB WHERE LEFT(id,7)='1001001'

Answer 5

还有的设计
id pid name   Detail
----------- ----------- --------------------   
1 0 食品  null
2 1 水果 食品->水果
3 1 蔬菜 食品->蔬菜
4 2 香蕉 食品->水果->香蕉
5 2 苹果 食品->水果->苹果
6 3 青菜 食品->水果->青菜这就是冗余
但是直接存了这种关系，这个关系有需要维护成本
但是便了一些情况下频繁的查询

Answer 6

标准做法有3种：
1、最早的做法：节点id里包括完整路径（曾祖父id-爷id-父id-本id）
财务的会计科目编号就是这么做的
现在基本很少使用了2、递归做法：父id，本id（更早、完整的关系提供递归才能得到）
目前比较普遍
好处是直观简单，增删方便
坏处是生成树需要递归3、直接保存法：本id，根id，层次数，在根（子树）里的序号
好像没看到别人这么用的，我在自己的树形论坛离线阅读器里采用过
好处是避免了递归，生成树记录高效方便
坏处是增删节点，需要更新半个子树的节点记录

Answer 7

只能
select * from (
cte递归
) a
where flevel=4