见过一种设计，将权限系统分为三种对象：用户、角色和组。
1. 角色是权限系统的基本单位，我们常常为角色赋予各种权限。同时角色可以赋予其他角色。
2. 用户，可以被赋予各种角色。同时可以被赋予各种权限。
3. 组，作用类似于文件夹，用于盛放用户与角色。同时可以被赋予各种角色。同时可以被赋予各种权限。
4. 权限管理中，存在特殊的角色：admin_role和group_admin_role。前者为系统管理员角色，后者为组管理员角色。
5. 系统中存在特殊用户：admin。此为系统管理员，不能删除、改变。
对于上述设计在实际情况中，发生了一些问题，或者说教训。
1. 创建角色role1、role2、role3，将role1赋予role2，role2赋予role3，role3赋予role1，这样在权限读取中会形成死循环。
2. 系统运行时，常常（经常进行这种运算）需要识别一个用户是否为系统管理员或组管理员或者其他权限。以判断某用户是否具备某种权限为例，常常需要这样：
a. 查看user是否具有此权限。时间复杂性为 ：O(1)。
b. 参看user被赋予的role，是否具有此权限。时间复杂性为 ：O(n)。
c. 层层遍历user所在组具备的权限，即这些组被赋予的role。时间复杂度为：O(n2)。
d. 递归遍历上述role中被赋予的role，是否具备此权限。时间复杂度为 ：我也不知道它的时间复杂度了。
3. 出现将admin_role或group_admin_role直接赋予到“组”上的情况。这样一组人都成了超级管理员或组管理员了。
4. 实际设计中，发现role只需要放置在根目录就可以了，不需要分组。而且如果将其放在其他组，会导致遍历权限的时间复杂度。
教训的总结：
1. 组和用户，不能直接被赋予权限。
2. 角色不能再赋予其他角色。
3. admin_role和group_admin_role在设计中，就应该和其他role区分开。对他们两个的进行一些限制，如不能被编辑，不能赋予组等。不设置这两个role，只是对user中设置单独的标记（是否为管理员），在用户编辑页面，提供“将此用户设为管理员”的勾选操作。
4. 将“role的结构树”从“用户、组的结构树”中独立出来，因为role的组织结构中，根本不需要“文件夹”这一概念。