- id _in _read _write _dump _backup
- 1001 1 1 0 0 0
- 1002 0 0 0 0 0
- 1003 1 1 1 1 0
- id name gender acl email
- 1001 张三 男 11000 ok@ok.com
再写一个readAcl类，每次根据具体的值得出相应的权限。这是小打小闹而已，因为：
1、数据大量冗余
当数据多的时候，就是说系统使用人数多的时候，或者部门业务较多，表中列就有二三十行的情况下，就会产生浪费，引发数据库反映变慢，究其原因在于这种方式太精细化了，可以控制每个人的每个活动。其实不需要这么设置，因为很多人只有几个项目有权限，别的权限相就都是0，如果真的发生了那样的事情，呵呵，咱们看到的表会是一个处处是0，几乎都看不见1的一个大表格。这不是浪费是什么。
2、可扩展性差
数据冗余就说明了，此处需要改进，而且那么多重复数据，第一眼看去就想给他面向对象进行拆分进行重用，呵呵，可惜那是数据库，虽不能面向对象，但可以拆表。其实，大家可以设想一下，如果这个公司业务发展情况良好，不久又兼并了一个新业务，那么咱就得在这个大表中再新增添一个列，又出现N多个0和极少量的1。如果说这你可以容忍，那么每次都对这个表增加列你还能容忍么？增加列之后，人员数据表里的acl字段值你就必须每次都重写一遍，因为之前是11000（五位），现在所有人都变为110000（六位），如果还有别的表也用到这个值呢？别忘了，你还得对PHP程序进行修改呢。
总之，你说麻烦不麻烦。
我靠，那怎么办？
是的，我也发愁ing。突然我想到了Linux，这可是可以一机带超多个用户的系统，它的权限设计是按组来分的。灵感告诉我，这是个好点子。于是我查看了Discuz和Joomla的用户权限设置，思路都是一样：按组分配权限。
万岁，首先还是那张用户表，可以固定字段罗：
- id name gender group email
- 1001 张三 男 0 ok@ok.com
这张表里变得更简单了，就一个数，代表组ID。
接着设定组权限表：
- id _in _read _write _dump _backup
- 0 1 1 1 1 1
- 1 0 0 0 0 0
- 2 1 1 0 1 0
接下来就是一个简单的组员表了。
- gid id
- 0 1001
- 0 1003
- 1 1129
- ............
这种做法在遇到超大量数据时都没有问题。关键是极好地解决了权限分配问题。其实看起来是种树状结构：
- groupA:
- 张三
- 李四
- groupB:
- 王五
- 赵六
- 陈七
- groupC:
- 周八
这一点，就写到这吧。