大家做系统,一般设置引用完整性吗?比如级联删除,级联修改等.还是在前台程序中实现引用的完整性呀?
------------------------
比如,员工表,员工编号是主键,部门编号是外键
部门表,部门编号是主键.
如果设置了级联删除,则如果删除一个部门,则员工表中该部门的所有员工信息就没了.如果这样设计的话,我认为风险大些.因为操作员有可能误删一个部门,如果误删,比如误删除财务部这个部门,则员工表中财务部的几十人的记录就全没了.后果比较严重.
如果不设置这个级联关系,数据库本身的功能又得不到充分利用,所以我一直不太明白,在现实的系统实现中,这类情况应该如何处理呀,谢谢.
------------------------
比如,员工表,员工编号是主键,部门编号是外键
部门表,部门编号是主键.
如果设置了级联删除,则如果删除一个部门,则员工表中该部门的所有员工信息就没了.如果这样设计的话,我认为风险大些.因为操作员有可能误删一个部门,如果误删,比如误删除财务部这个部门,则员工表中财务部的几十人的记录就全没了.后果比较严重.
如果不设置这个级联关系,数据库本身的功能又得不到充分利用,所以我一直不太明白,在现实的系统实现中,这类情况应该如何处理呀,谢谢.
简单的例子就是你现在的情况,
可以在前台程序中通过严谨的业务逻辑的控制进行删除
也可以通过设置级联关系
还可以通过触发器来进行怎么做好,我觉得有一个原则,那就是影响业务逻辑的东西,尽量不要利用数据库端实现.比如,在某个系统中有用户表, 从业务上讲,用户表用一个就可以了,开发人员考滤到某些字段使用频率不高,且字段比较大,从性能和冗余两方面出发,他将用户表进行了分表存储.
这种情况,分表不是由业务逻辑要求,那么这时做法最好是通过设置级联关系.而你的问题,是由业务要求引起的分表设置,我个人建议在前台程序中完成
比如员工表，我做过的系统从不会删除员工，如果员工离职了只是做一个标志，不会删除的，删除或是把这个工号给另一个人使用都会带来管理及查询历史的不当之处，
这种简单的错误是犯不着让用户去触发的（很没有面子啊），应该在测试阶段就改正了。
比如员工表，我做过的系统从不会删除员工，如果员工离职了只是做一个标志，不会删除的，删除或是把这个工号给另一个人使用都会带来管理及查询历史的不当之处，
-----------------
我已有同感呀,单位的人力管理系统,就是这样,人离职了,系统删了,可是过几个月人又回来了,又要增加.
如果当时的系统是做的删除标记就好了.现在要我手工从数据库历史记录中找到,然后再加进来.麻烦.
(一定要保证,一个人不能有多个编号呀,否则就乱了.)