题记：

  熟话说：男怕入错行，女怕嫁错郎！ 掐指一算入行IT业，已7年的码农生涯。在今天来看，其实IT行业，要做点事情不没有想象中的那么难，可是为啥只知道上班、下班，有时面对自己无言以对啊！这么多年没给自己留下什么有形资产，实属遗憾！

 苏联作家尼古拉·奥斯特洛夫斯基 在《钢铁是怎样炼成的》一书中，有一段话很是经典，让我们再次回顾一遍吧：人最宝贵的东西是生命.生命对人来说只有一次.因此,人的一生应当这样度过:当一个人回首往事时,不因虚度年华而悔恨,也不因碌碌无为而羞愧;这样,在他临死的时候, 能够说, 我把整个生命和全部精力都献给了人生最宝贵的事业——为人类的解放而奋斗。我们必须抓紧时间生活，因为即使是一场暴病或意外都可能终止生命。

好了，咱们言归正传，今天这里主要来讨论一下信息系统的权限设计的问题，由于时间和精力有限，本文将会关键点展开必要的讨论和说明，对于细节部分将会省略。 需要特别说明的是，这并不表示本文只是泛泛而谈，相反，下面呈现的内容是经过反复思考而得出，也许在大牛们看来，下面的内容都是小case, 哪就当我在此献丑了，你也可以发表一下高见!

各位看官， 我非常乐意也很渴望和各位交流，所以，关于话题内、外的问题，可以在此展开讨论！

权限分类

关于系统的权限设计，主要分为两类：

一、功能权限

在功能权限中，又可以分为:

1.1: 菜单权限

      一般菜单权限都是通过，是否可见（隐藏）来达到权限控制的目的。

1.2: 操作权限

     操作权限除了是否可见（隐藏）来达到控制之外，还可以通过是否可用（enable/disable)来实现控制。

二、数据权限

基于关系型数据库设计的信息系统，数据的权限可以分为：

2.1:  横向的数据权限

       也就是说，（在不考虑纵向的情况下）作为销售人员：Robin, Jack, Frank 可以分别看到他们所在行的数据，即：Robin 可以看到订单编号为001， 003所在的行的数据。 而Jack 可以看订单编号为002所在行的数据，Frank 看到004所在行。

2.2:  纵向的数据权限 （在本文的权限设计中，没有实现纵向的数据控制功能，待以后有需要再考虑）

       居于某种策略，公司可能会把真正的成本价格隐藏（即：上表中“成本价格”这一列所有销售人员是看不到的， 只会告诉销售人员，销售价格不能低于4，上不封顶，利润分成）

权限管理

权限管理的策略有很多，这里就不展开，大家可以再百度看看，这里介绍主要是居于角色的权限管理， 在现实生活中，我们知道什么人就干什么活（指的是角色或者职业）。

如：老师教书，学生就是学习（可以进行听、说、读、写等活动），同样在信息系统中也是一样。

居于以上分析，抽象出如下的权限系统表结构设计（如下图）：

相关说明如下：

1. 所有粉色的表， 表示关联表（即作为实体之间的桥梁作用） 

2. 用户组----- 这里设计用户组是处理大量数据的需要， 如果某个组（部门）有好几百号人，我需要给他们赋予权限，（如果没有组，那就需要一个个去赋权），有了组，我们只想给这个组赋予权限。

3. 用户角色表-----这个事用户之间和角色关联，为的是某些时候有些人（个别情况），喜欢搞特殊化，这样就不用绕弯了，直接赋权。

4.  菜单操作表， 功能权限表， 这两个表在图中都有说明,可以慢慢琢磨。

5. 数据权限 ---  这里主要说下（横向的）数据权限是如何控制的:

     数据维度类型---  由于横向的数据权限可以有多个维度，从上面销售表中，我们的维度是“销售人员”（如果销售人员自己录单到系统的话，那应该就是创建者自己），除此之外，维度还可以是：公司、部门、银行.....

     即，A公司不能看B公司数据（反之亦然） ； X部门不能看Y部门的数据(反之亦然），  m银行不能查看n银行的数据（反正亦然）。

    要实现这些都必须在业务表中有对应的属性，比如上面例子中 “销售人员”， 部门，银行

    补充：刚才也说了，如果一个部门有好几百人时，领导要看他们的数据，这里就要将每一个用户的编号插入到 ”数据维度值“，

            方式A:   如果采用文本设计，最后取数的时候用SQL:  in ( ‘user001‘, ‘user002‘, ‘user003‘, .....);    这样也不失为一种方式，如果需要一些大的数据量，复杂情况，可能导致性能低下，SQL in 是全表扫描的,不利于优化.

           方式B:   可以为每一个值增加一条记录（即：数据维度表中，除了”数据权限ID" 主角值， "数据维度值“不一样，其他值均一样，并且可能导致数据爆炸式的增长，比如其他维度的数据值，非常多的情况）

            方式C:   在B的基础上， 将”数据维度值“ 生成一个序号， 将具体的值和该序号管理起来，存放在另外一个表中（或者另外多个表中，当采取多个表的情况，可以根据数据维度类型来设计表的命名）。          

 6.  功能权限表-----在这个表中，为了在查询时候一目了然的看到 “菜单编码”，  "操作编码“ 已经相应的可见性，可操作性， 这样就一目了然，不用查多张表连接了。

后记问题

1.  如果是纵向的数据权限该如何设计表好？（各位，大家积极发言哈，知无不言，言无不尽）

2.  各类ID用设么类型比较好INT,  LONG,  VARCHAR  有的时候还确实挺纠结的，各位有什么号的建议或者，不妨说说看.....(体现各种价值的机会无处不在，但要抓紧哦....）

3.  如果在后期, 纵向数据权限添加进来，这种权限模式对系统性能的影响做如何权衡和考虑？ 

4.  由于比较少写博客，有不周到之处，还请见谅，感谢各位，希望大家积极发言，展开讨论！！！

信息系统的权限设计