希望这些建议,能推动管理软件开发的规范化进程 (数据按权限过滤)

希望大家建立表格时,都按以下建议做一个参考。
  1. CompanyID nvarchar 40 这个数据是哪个公司的
  2. [可省略]CompanyFullName nvarchar 40 公司的名称
  3. DepartmentID nvarchar 40 这个数据是哪个部门的
  4. [可省略]DepartmentFullName nvarchar 40 这个部门的名称
  5. StaffID nvarchar 40 这个数据是哪个员工的姓名 
  6. [可省略]StaffFullName nvarchar 40 这个员工的姓名
当然以上表格的设计,主导思想。
1. 普通员工只能看自己的数据,不能看别人的数据,更不能修改别人数据了,
这时候,数据可以按 StaffID 进行过滤就可以了。
2. 部门主管可以看自己部门的数据,那可以用 DepaertmentID 进行过滤。
3. 公司的经理层,可以看自己公司的数据,那可以用 CompanyID 进行过滤。
以上当然是最简单的几个几个场景,还需要更复杂的情况,
例如 A只可以看 B、 C的数据,那就用 StaffID IN ('A', 'B') 类似来解决问题。
 
StaffID, 与 UserID 的区别,Staff 表示是这个公司的正式员工。
UserID  表示这个系统的用户,可能不是这个公司的职工,也可能是客户。

有些软件设计人员,设计程序时,想得有些不稳妥,例如,你会说CompanyIDDepartmentID 都可以通过
StaffID 可以计算得出,当然那些FullName那些,也都可以通过以上的计算,能获得出数据,按这个思路来考虑
问题,的确数据有很多冗余了。

我们猜想一下,我以前在宁波东蓝科技工作,犹豫家里的原因,我工作1年多后,调动到杭州分公司工作了,我的
个人ID在同一个集团公司里,是没有变化的,但是我的公司已经变了,部门也变了,以前的数据是属于宁波公司,
而不是属于杭州公司的,而且人员的调动,公司之间的调动,部门之间的调动,甚至借用人员都是很普遍存在的问题。

还有,一个业务表里的数据很多,那要跟其他表进行关联才能获得其他数据,这时候,写SQL语句很烦恼,而且有时候
部门的名字,单位的名字也可能会有变化,以前的数据就是那个部门的叫那个名字时的数据,所以还是保留起来,也可以
写sql模糊查询等很方便,还有我们打个比方,我们整个集团的数据都存储在宁波,例如有统一的数据中心,在保管着
我们整个集团的组织架构、职员信息、权限分配、工作流程配置等,我们本地的业务数据库里是没有 部门、人员表的。
那这样的情况下,应该保存当时的部门职员的名字,还是比较合适的。 
将权限管理、工作流管理做到我能力的极致,一个人只能做好那么很少的几件事情。




本文转自 jirigala 51CTO博客,原文链接:http://blog.51cto.com/2347979/451734,如需转载请自行联系原作者
上一篇:【趣话编程】一个Java对象的回忆录:垃圾回收


下一篇:《jQuery Cookbook中文版》——1.10 创建、操作和插入DOM元素