其中一个酒店的部门可能是多级形式，而且每个酒店下的部门都会在几十个，而且部门设置都差不多
第一种方法设计，一个表实现
编号 名称 父编号 编码
1 集团总部 0
2 广州某酒店 1 01
3 财务部 2 0101
4 收银部 2 0102
5 公关部 2 0103
6 康乐部 2 0104
7 游泳池 6 010401
8 网球场 6 010402
9 桌球室 6 010403
这种方法存在的问题的是，如果要是新增很多酒店，就会增加很多部门数据
第二种方法 三个表设计
表1,公司表
表2、把所有部门抽出来形成一个不重复的部门表
表3、公司和部门关系表
虽然这种设计添加部门比较容易，但也存在问题，不能很好体现部门各级关系，最终不能形成一个公司、部门树
希望更多的人提出方法
15 个解决方案
#1
个人建议第一种
#2
第一种不错， 你部门表数据再多也多不过1W条吧 ，即便是多过了， 通过索引处理一下 不会影响速度就好， 至于数据的多少应该没什么关系吧
#3
你的表2 可以设计成不重复的部门各级关系表
编号 部门 父编号
编号 部门 父编号
#4
本人觉得第二种方法 三个表设计
表1,公司表
表2、把所有部门抽出来形成一个不重复的部门表
表3、公司和部门关系表
比较好
表1,公司表
表2、把所有部门抽出来形成一个不重复的部门表
表3、公司和部门关系表
比较好
#5
第二种方法 三个表设计
表1,公司表
表2、把所有部门抽出来形成一个不重复的部门表
表3、公司和部门关系表
虽然这种设计添加部门比较容易，但也存在问题，不能很好体现部门各级关系，最终不能形成一个公司、部门树
这个比较符合范式
至于各级关系，可通过适当sql表达
表1,公司表
表2、把所有部门抽出来形成一个不重复的部门表
表3、公司和部门关系表
虽然这种设计添加部门比较容易，但也存在问题，不能很好体现部门各级关系，最终不能形成一个公司、部门树
这个比较符合范式
至于各级关系，可通过适当sql表达
#6
为什么不考虑用两种表实现呢？
ctlm01 com_id ,dept_id,dept_abbr(主表)
ctlm02 com_id ,dept_id,subdept_id,dept_abbr(次表)
在根造树的过程中，可以根据表ctlm01的dept_id 去对应所ctlm02中的dept_id中的subdept_id
。。。。。。。。。
这样我觉得比较简单。
ctlm01 com_id ,dept_id,dept_abbr(主表)
ctlm02 com_id ,dept_id,subdept_id,dept_abbr(次表)
在根造树的过程中，可以根据表ctlm01的dept_id 去对应所ctlm02中的dept_id中的subdept_id
。。。。。。。。。
这样我觉得比较简单。
#7
这个可以对部门表，创建为一个代码表
然后采用第一种设计方式来创建表，那么公司是一张表，部门是就会有公司和部门代码表的2个外键，这样应该也不会错。
而且对于不同的公司统一的部门也好做数据统计。
实在的也是第一种的设计模式
然后采用第一种设计方式来创建表，那么公司是一张表，部门是就会有公司和部门代码表的2个外键，这样应该也不会错。
而且对于不同的公司统一的部门也好做数据统计。
实在的也是第一种的设计模式
#8
一个表即可。
#9
一个表是好,但加一个公司,然后就要新增几百个总部或者机构也是很麻烦的事,而且统一的部份实现数据统计也比较麻烦,第二种方法用三张表是可行,但表就比较多了
#10
一个表是好,但加一个公司,然后就要新增几百个部门或者机构也是很麻烦的事,而且统一的部门实现数据统计也比较麻烦,第二种方法用三张表是可行,但表就比较多了
#11
怎么没有人来了,我自己顶一下
#12
第一种方法
A酒店和B酒店的财务部是区别的，不同基础数据应有不同的基本码。
A酒店和B酒店的财务部是区别的，不同基础数据应有不同的基本码。
#13
当然这种设计是基于集中型数据管理的。
另外，如果嫌新增麻烦，你可以提供一个类似创建的功能，可以通过程序代码或存储过程实现。
一点意见，作为连锁，必然有业务的独立性，还是建议分布型数据库。
另外，如果嫌新增麻烦，你可以提供一个类似创建的功能，可以通过程序代码或存储过程实现。
一点意见，作为连锁，必然有业务的独立性，还是建议分布型数据库。
#14
比较一下：
1、表的维护方面：
第一种方法在新增，修改、删除部门时比较麻烦，因为需要检索所有的公司。
第二种方法在修改时非常简单，但在新增、删除时貌似简单，其时不然，因为需要对公司、部门关系表进行相应操作，只比第一种方式简单了一些。
2、表的使用方面：
第一种方式比较容易构建树型，结构简单；在引用时只需一个字段：部门代码（可以通过树获得其它信息）。
第二种方式也可以构建树型结构，但比较繁琐，而且结构复杂；在引用时需要两个字段：公司代码、部门代码。
3、表的扩展方面：
第一种方式可以任意扩展，对程序没有什么影响。
第二种方式有两种可能，一是一级部门可以在各公司不一样，二级部门及以下必须一样，在构建公司部门关系表时只需建立公司与一级部门的关系表，二级及以下部门通过一级部门关联到公司，这样在扩展方面就受到限制，二是不管部门级别，都与公司建立关系，这样做其扩展性与第一种一样，但明显的多此一举。
因此，应该用哪种方式楼主还是应根据情况自己分析了。
1、表的维护方面：
第一种方法在新增，修改、删除部门时比较麻烦，因为需要检索所有的公司。
第二种方法在修改时非常简单，但在新增、删除时貌似简单，其时不然，因为需要对公司、部门关系表进行相应操作，只比第一种方式简单了一些。
2、表的使用方面：
第一种方式比较容易构建树型，结构简单；在引用时只需一个字段：部门代码（可以通过树获得其它信息）。
第二种方式也可以构建树型结构，但比较繁琐，而且结构复杂；在引用时需要两个字段：公司代码、部门代码。
3、表的扩展方面：
第一种方式可以任意扩展，对程序没有什么影响。
第二种方式有两种可能，一是一级部门可以在各公司不一样，二级部门及以下必须一样，在构建公司部门关系表时只需建立公司与一级部门的关系表，二级及以下部门通过一级部门关联到公司，这样在扩展方面就受到限制，二是不管部门级别，都与公司建立关系，这样做其扩展性与第一种一样，但明显的多此一举。
因此，应该用哪种方式楼主还是应根据情况自己分析了。
#15
另:
1、既能是连锁集团，部门的配置应该是一样的才对（由于地域不同，有些部门为空部门而已，并且表报应该一致，即便是空部门也应该列上）。
2、公司（或者称为法人）和部门的对象是不一样的，不能归并到一个表中，公司有地址、帐号等等，部门有办公室等。
1、既能是连锁集团，部门的配置应该是一样的才对（由于地域不同，有些部门为空部门而已，并且表报应该一致，即便是空部门也应该列上）。
2、公司（或者称为法人）和部门的对象是不一样的，不能归并到一个表中，公司有地址、帐号等等，部门有办公室等。
#1
个人建议第一种
#2
第一种不错， 你部门表数据再多也多不过1W条吧 ，即便是多过了， 通过索引处理一下 不会影响速度就好， 至于数据的多少应该没什么关系吧
#3
你的表2 可以设计成不重复的部门各级关系表
编号 部门 父编号
编号 部门 父编号
#4
本人觉得第二种方法 三个表设计
表1,公司表
表2、把所有部门抽出来形成一个不重复的部门表
表3、公司和部门关系表
比较好
表1,公司表
表2、把所有部门抽出来形成一个不重复的部门表
表3、公司和部门关系表
比较好
#5
第二种方法 三个表设计
表1,公司表
表2、把所有部门抽出来形成一个不重复的部门表
表3、公司和部门关系表
虽然这种设计添加部门比较容易，但也存在问题，不能很好体现部门各级关系，最终不能形成一个公司、部门树
这个比较符合范式
至于各级关系，可通过适当sql表达
表1,公司表
表2、把所有部门抽出来形成一个不重复的部门表
表3、公司和部门关系表
虽然这种设计添加部门比较容易，但也存在问题，不能很好体现部门各级关系，最终不能形成一个公司、部门树
这个比较符合范式
至于各级关系，可通过适当sql表达
#6
为什么不考虑用两种表实现呢？
ctlm01 com_id ,dept_id,dept_abbr(主表)
ctlm02 com_id ,dept_id,subdept_id,dept_abbr(次表)
在根造树的过程中，可以根据表ctlm01的dept_id 去对应所ctlm02中的dept_id中的subdept_id
。。。。。。。。。
这样我觉得比较简单。
ctlm01 com_id ,dept_id,dept_abbr(主表)
ctlm02 com_id ,dept_id,subdept_id,dept_abbr(次表)
在根造树的过程中，可以根据表ctlm01的dept_id 去对应所ctlm02中的dept_id中的subdept_id
。。。。。。。。。
这样我觉得比较简单。
#7
这个可以对部门表，创建为一个代码表
然后采用第一种设计方式来创建表，那么公司是一张表，部门是就会有公司和部门代码表的2个外键，这样应该也不会错。
而且对于不同的公司统一的部门也好做数据统计。
实在的也是第一种的设计模式
然后采用第一种设计方式来创建表，那么公司是一张表，部门是就会有公司和部门代码表的2个外键，这样应该也不会错。
而且对于不同的公司统一的部门也好做数据统计。
实在的也是第一种的设计模式
#8
一个表即可。
#9
一个表是好,但加一个公司,然后就要新增几百个总部或者机构也是很麻烦的事,而且统一的部份实现数据统计也比较麻烦,第二种方法用三张表是可行,但表就比较多了
#10
一个表是好,但加一个公司,然后就要新增几百个部门或者机构也是很麻烦的事,而且统一的部门实现数据统计也比较麻烦,第二种方法用三张表是可行,但表就比较多了
#11
怎么没有人来了,我自己顶一下
#12
第一种方法
A酒店和B酒店的财务部是区别的，不同基础数据应有不同的基本码。
A酒店和B酒店的财务部是区别的，不同基础数据应有不同的基本码。
#13
当然这种设计是基于集中型数据管理的。
另外，如果嫌新增麻烦，你可以提供一个类似创建的功能，可以通过程序代码或存储过程实现。
一点意见，作为连锁，必然有业务的独立性，还是建议分布型数据库。
另外，如果嫌新增麻烦，你可以提供一个类似创建的功能，可以通过程序代码或存储过程实现。
一点意见，作为连锁，必然有业务的独立性，还是建议分布型数据库。
#14
比较一下：
1、表的维护方面：
第一种方法在新增，修改、删除部门时比较麻烦，因为需要检索所有的公司。
第二种方法在修改时非常简单，但在新增、删除时貌似简单，其时不然，因为需要对公司、部门关系表进行相应操作，只比第一种方式简单了一些。
2、表的使用方面：
第一种方式比较容易构建树型，结构简单；在引用时只需一个字段：部门代码（可以通过树获得其它信息）。
第二种方式也可以构建树型结构，但比较繁琐，而且结构复杂；在引用时需要两个字段：公司代码、部门代码。
3、表的扩展方面：
第一种方式可以任意扩展，对程序没有什么影响。
第二种方式有两种可能，一是一级部门可以在各公司不一样，二级部门及以下必须一样，在构建公司部门关系表时只需建立公司与一级部门的关系表，二级及以下部门通过一级部门关联到公司，这样在扩展方面就受到限制，二是不管部门级别，都与公司建立关系，这样做其扩展性与第一种一样，但明显的多此一举。
因此，应该用哪种方式楼主还是应根据情况自己分析了。
1、表的维护方面：
第一种方法在新增，修改、删除部门时比较麻烦，因为需要检索所有的公司。
第二种方法在修改时非常简单，但在新增、删除时貌似简单，其时不然，因为需要对公司、部门关系表进行相应操作，只比第一种方式简单了一些。
2、表的使用方面：
第一种方式比较容易构建树型，结构简单；在引用时只需一个字段：部门代码（可以通过树获得其它信息）。
第二种方式也可以构建树型结构，但比较繁琐，而且结构复杂；在引用时需要两个字段：公司代码、部门代码。
3、表的扩展方面：
第一种方式可以任意扩展，对程序没有什么影响。
第二种方式有两种可能，一是一级部门可以在各公司不一样，二级部门及以下必须一样，在构建公司部门关系表时只需建立公司与一级部门的关系表，二级及以下部门通过一级部门关联到公司，这样在扩展方面就受到限制，二是不管部门级别，都与公司建立关系，这样做其扩展性与第一种一样，但明显的多此一举。
因此，应该用哪种方式楼主还是应根据情况自己分析了。
#15
另:
1、既能是连锁集团，部门的配置应该是一样的才对（由于地域不同，有些部门为空部门而已，并且表报应该一致，即便是空部门也应该列上）。
2、公司（或者称为法人）和部门的对象是不一样的，不能归并到一个表中，公司有地址、帐号等等，部门有办公室等。
1、既能是连锁集团，部门的配置应该是一样的才对（由于地域不同，有些部门为空部门而已，并且表报应该一致，即便是空部门也应该列上）。
2、公司（或者称为法人）和部门的对象是不一样的，不能归并到一个表中，公司有地址、帐号等等，部门有办公室等。