我目前正在为本地协会开发成员管理，目前正在开发数据库模式。我想与您分享它以改进它，并为其他人提供基于角色的访问模型 (RBAC) 的示例。我将不胜感激任何建设性的批评，尤其是关于我在表格之间使用的关系。
链接到高分辨率：http: //i.stack.imgur.com/WG3Vz.png
继承人的架构：
这个怎么运作：
我正在将现有客户（实际上是协会的成员）从外部应用程序映射到我的管理应用程序中。（客户表）
该关联在 Division、Subdivisions 等中结构化（intern_structures 表）。每个客户都可以是多个部门、子部门、部门等的成员。
每个客户都可以在此类会员（部门，...）中担任一个或多个角色，例如总裁，精算师，财务主管等，并且每个角色都具有某些特权，该角色的所有者可以将其应用于其部门，细分，部门等中的其他人.
凭证与应用程序的某个操作相关联。凭证的所有者可以对他范围内的其他成员执行此操作。可以有多个“独立”应用程序，但它们都共享相同的身份验证/授权系统。
应用程序由模块/子模块/操作等构成。示例可能是“个人详细信息”模块，该模块包含一个名为“图片”的子模块，您可以在此图片上应用“查看、删除、编辑”操作。但是您不能删除任何图片，除非您尝试删除其图片的人在您有足够角色的部门/部门中。
内部结构和应用结构都是树，实现为邻接表和嵌套集。邻接表确保完整性，嵌套集允许我快速遍历树。
一个例外是您可以直接向某人提供某些凭据（client_credentials）。如果有人需要对不在他的部门/部分中的人执行某些操作，则需要这样做。
因此，某人可以成为多个部门/部门的成员，并在他所属的每个部门/部门中获得多个角色。我将合并某人通过他的多个角色拥有的所有凭据。并且凭证总是正面的，这意味着限制性凭证是不可能的。