当前位置: 代码迷 >> Sql Server >> 这个数据库表的设计如何优化
  详细解决方案

这个数据库表的设计如何优化

热度:78   发布时间:2016-04-24 18:35:25.0
这个数据库表的设计怎么优化?
软件工程作业要写一个超市员工管理系统,我用Access作为数据库,设计了一个员工信息表结构如下:
员工号
姓名
性别
出生日期
学历
电话
是否管理人员
部门
职位

当初我没有分成员工和管理人员2个表,是考虑他们统一编号(员工号),而且员工可以升职为管理人员(主管、副经理、总经理),管理人员也可以降职为员工。
现在感觉这个表有冗余(是否管理人员、职位),而且写程序的时候要判断是否管理人员和职位是不是冲突,怎么设计更好呢?
如果分2个表,员工号怎么处理?
------解决方案--------------------
建议设计,

员工信息表: 员工号,姓名,性别,出生日期,学历,电话,部门,职位..

职位信息表: 部门,职位,是否管理人员..
------解决方案--------------------
引用:
我原来想的员工号是可以做成工号牌的员工号,所以必须是Unique的。

I agree with you.
------解决方案--------------------
其实一个表就足够了.

如果一定要2个表的话,可以这样设计,
员工表: 员工号,姓名,性别,出生日期,学历,电话,部门,职位.. 
 例如[员工号]以E开头,E001,E002... 

管理人员表: 管理人员号,姓名,性别,出生日期,学历,电话,部门,职位..  
 例如[管理人员号]以M开头,M001,M002...
------解决方案--------------------
引用:
如果一个员工升职为管理人员,那要重新编号了?

可以把资料记录从与员工表转移到管理人员表.
原来的员工表继续递增的编号,不重复使用这个升职的员工号.
------解决方案--------------------
引用:
升职以后再降职回来,编号可能又不是原来编号了。

可以把资料记录从管理人员表转移到员工表.
------解决方案--------------------
引用:
我想最好编号像身份ID一样,终身不变的。
不过主键可以不用它。

升职/降至均用记录转移的方法,身份ID就是终身不变的.
------解决方案--------------------
引用:
看来还是一个表好了。

Right.

------解决方案--------------------
工号不应该变吧?职位单独出一个表,员工表带个职位ID,就可以减少冗余
------解决方案--------------------
如果用户或者业务非要2个表对员工和管理员分表存储,但你又要求ID像身份证一样唯一,这也好办,你给这两个表分别加插入触发器,在插入前都要检查另外的表是否有这个ID,从而保证唯一
------解决方案--------------------
象这样的情况,一般按如下的方式:
1、员工基础信息表:员工号、姓名
2、部门信息表:部门代号、部门名称...
3、职位信息表:职位代号、...(取决于你的职位级别是否复杂,不复杂就不需要专门的基础表)
4、员工职位表:部门代号、员工号、职位代号....

这样的结构,是否看明白?

------解决方案--------------------
引用:
Quote: 引用:

象这样的情况,一般按如下的方式:
1、员工基础信息表:员工号、姓名
2、部门信息表:部门代号、部门名称...
3、职位信息表:职位代号、...(取决于你的职位级别是否复杂,不复杂就不需要专门的基础表)
4、员工职位表:部门代号、员工号、职位代号....

这样的结构,是否看明白?

我这是很小型的,感觉这样太复杂,连接起来效率也不高。


呵呵,这个和小型、大型关系不大,这个是按照3NF设计规范来设计的,减少数据的冗余,保持数据的一致性。
------解决方案--------------------
引用:
Quote: 引用:

象这样的情况,一般按如下的方式:
1、员工基础信息表:员工号、姓名
2、部门信息表:部门代号、部门名称...
3、职位信息表:职位代号、...(取决于你的职位级别是否复杂,不复杂就不需要专门的基础表)
4、员工职位表:部门代号、员工号、职位代号....

这样的结构,是否看明白?

我这是很小型的,感觉这样太复杂,连接起来效率也不高。


   这要取决于你是要良好的设计风格,还是简单的方式了。
   按你所说的逻辑“现在感觉这个表有冗余(是否管理人员、职位),而且写程序的时候要判断是否管理人员和职位是不是冲突,怎么设计更好呢?” 如果不分开处理,那判断起来也不方便,因为数据填写不规范,如:部门写为“财务部” 或“财务”,会导致判断失去意义。
   从软件开发的角度出发,无论系统大小,按良好的设计风格,对以后的扩展、个人的能力提升,都是有帮助的。
   个人建议,仅供参考。
  相关解决方案