我目前正在为这里的一个本地协会开发会员管理系统，并且正在制定数据库架构。我想与你分享它，以便改进它，并为其他人提供基于角色的访问模型（RBAC）的示例。我特别希望得到有建设性的批评，尤其是关于我在表格之间使用的关系。
高分辨率链接：https://istack.dev59.com/WG3Vz.webp
这是架构图：
它是如何工作的：
我正在将现有客户（实际上是协会成员）从外部应用程序映射到我的管理应用程序中。（客户表）
该协会按照分部、子分部等组织结构进行管理（intern_structures表）。每个客户可以成为多个分部、子分部、小组等的成员。
每个客户在这些成员身份（分部等）中都可以担任一种或多种角色，例如主席、秘书、财务等，每种角色都有一定的权限，角色所有者可以在他所在的分部、子分部、小组等中对其他成员应用这些权限。
凭据与应用程序的某个操作相关联。凭据所有者可以在他的范围内对其他成员执行此操作。可能有多个“独立”的应用程序，但它们都共享相同的身份验证/授权系统。
应用程序按模块/子模块/操作等进行组织。例如，“个人详细信息”模块包含名为“图片”的子模块，您可以对该图片应用“查看、删除、编辑”等操作。但是，除非您拥有适当的角色来执行此操作所在的分部/小组中的人，否则您无法删除任何图片。
内部和应用程序结构都是树，实现为邻接列表和嵌套集。邻接列表确保完整性，而嵌套集可让我快速遍历树。
一个例外是您可以直接向某人授予某些凭据（client_credentials）。如果有人需要对不在他的分部/小组中的某人执行某些操作，则需要这样做。
因此，一个人可以在多个部门/部分成为成员，并在他加入的每个部门/部分中获得多个角色。我将合并某个人通过他的多个角色所拥有的所有凭据。而且凭据始终是积极的，这意味着不可能出现限制性凭据。