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

[ahking]

首先是分级的组织结构
集团公司/分公司/部门/组/...
然后是人员，可能同时属于某几个组的管辖

要求：
1、能够根据层次表生成树状菜单
2、能够快速获取某个级别或某个级别的指定部门的所有人员

该如何设计表才比较合理呢？

[开启时代]

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

[汤姆克鲁斯]

数据数据量不大就是父子关系结构了

id pid name
----------- ----------- --------------------
1 0 食品
2 1 水果
3 1 蔬菜
4 2 香蕉
5 2 苹果
6 3 青菜

可以用递归来找相应的父子关系
但是递归总是有性能瓶颈的，数据量偏大的递归就不考虑了
会有一些冗余设计。

[ahking]

[Quote=引用 1 楼 的回复:]

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

如何解决某个人同属于两个部门管辖的问题

[ahking]

[Quote=引用 2 楼 的回复:]

数据数据量不大就是父子关系结构了

id pid name
----------- ----------- --------------------
1 0 食品
2 1 水果
3 1 蔬菜
4 2 香蕉
5 2 苹果
6 3 青菜

可以用递归来找相应的父子关系
但是递归总是有性能瓶颈的，数据量偏大的递归就不考虑了
会有一些冗余设计。
[/Quote]

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

[开启时代]

[Quote=引用 3 楼 的回复:]
引用 1 楼 的回复:

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


如何解决某个人同属于两个部门管辖的问题
[/Quote]
员工组织表放多条数据即可。

[ahking]

这个表尽量保持每个员工的唯一性

而且这种递归设计实现要求的查询很复杂

[汤姆克鲁斯]

[Quote=引用 4 楼 的回复:]

引用 2 楼 的回复:

数据数据量不大就是父子关系结构了

id pid name
----------- ----------- --------------------
1 0 食品
2 1 水果
3 1 蔬菜
4 2 香蕉
5 2 苹果
6 3 青菜

可以用递归来找相应的父子关系
但是递归总是有性能瓶颈的，数据量偏大的递归就不考虑了
会有一些冗余设计。
……
[/Quote]
同一个人问的啊

[开启时代]

[Quote=引用 6 楼 的回复:]
这个表尽量保持每个员工的唯一性

而且这种递归设计实现要求的查询很复杂
[/Quote]

查询复杂？写个好的过程就行了

[汤姆克鲁斯]

id pid name
1001 0 食品
1001001 1001 水果
1001002 1001 蔬菜
1001001001 1001002 香蕉
1001001002 1001002 苹果
1001002001 1001002 青菜

--比如这样的结构 要查询水果以及他的所有下级

SELECT * FROM TB WHERE LEFT(id,7)='1001001'

[汤姆克鲁斯]

还有的设计
id pid name Detail
----------- ----------- --------------------
1 0 食品 null
2 1 水果 食品->水果
3 1 蔬菜 食品->蔬菜
4 2 香蕉 食品->水果->香蕉
5 2 苹果 食品->水果->苹果
6 3 青菜 食品->水果->青菜

这就是冗余
但是直接存了这种关系，这个关系有需要维护成本
但是便了一些情况下频繁的查询

[haitao]

标准做法有3种：
1、最早的做法：节点id里包括完整路径（曾祖父id-爷id-父id-本id）
财务的会计科目编号就是这么做的
现在基本很少使用了

2、递归做法：父id，本id（更早、完整的关系提供递归才能得到）
目前比较普遍
好处是直观简单，增删方便
坏处是生成树需要递归

3、直接保存法：本id，根id，层次数，在根（子树）里的序号
好像没看到别人这么用的，我在自己的树形论坛离线阅读器里采用过
好处是避免了递归，生成树记录高效方便
坏处是增删节点，需要更新半个子树的节点记录

[zhazhuzhao]

想说的都让前面的说了。
另外说一下，上面的设计就是方便向下扩展；如果不考虑向下扩展，并且结构很问题的话，可以用多表，每个表放一个层次的数据，这个是比较笨的方式来。

[ahking]

[Quote=引用 11 楼 的回复:]

标准做法有3种：
1、最早的做法：节点id里包括完整路径（曾祖父id-爷id-父id-本id）
财务的会计科目编号就是这么做的
现在基本很少使用了

2、递归做法：父id，本id（更早、完整的关系提供递归才能得到）
目前比较普遍
好处是直观简单，增删方便
坏处是生成树需要递归

3、直接保存法：本id，根id，层次数，在根（子树）里的序号
好像没看到别人这么用的，我在自己的……
[/Quote]

第二种，递归做法
我遇到的最大的不方便的地方就是
快速获取某个级别或某个级别的指定部门的所有人员
相当不方便

[ahking]

人员信息在另一张表中

[haitao]

[Quote=引用 13 楼 的回复:]
快速获取某个级别或某个级别的指定部门的所有人员
[/Quote]

只能

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

[haitao]

复杂没差多少
慢可能没办法：要先得到完整的树

[ahking]

[Quote=引用 15 楼 的回复:]

引用 13 楼 的回复:
快速获取某个级别或某个级别的指定部门的所有人员


只能
SQL code
select * from (
cte递归
) a
where flevel=4
[/Quote]

复杂，而且慢吧