此数据的最佳关系数据库结构

Question

我正在为以下场景创建数据库方案：

• 有用户
• 用户具有角色（例如“开发人员”或“CEO”）
• 角色有应用程序（例如“Topdesk”）
• 应用程序具有权限（例如“更新知识库”）
• 如果角色已经有权访问应用程序，则该角色可以拥有权限

假设没有高性能环境（无需优化速度），实现此模式的最佳方法是什么？数据库环境可以是MySQL、MSSQL……更多的是关系型数据库的设计。

我自己提出了以下几点：

我最不确定的部分当然是 Applications_Permissions_Roles 表。它是另一个链接表之上的链接表。我以前从未使用或见过这个。另一种方法是用角色和权限之间的链接表替换它，然后使用代码或约束来确保所需的关系......但这对我来说似乎不是一个好的解决方案。如果可能的话，这些事情应该在数据库级别强制执行（并且看起来可能），而不是在代码级别执行。

其次，是否需要 Permissions.Application 和 Applications.Id 之间的链接？我使用它是因为 Roles_Applications 中可能没有任何行（例如，当您刚刚添加了一个新应用程序时），然后无法确定哪些权限属于哪个应用程序。它也是查找权限所属的应用程序的单一参考点。我想这是对的，但它也在数据库设计中绕了一圈。尝试将 ON_DELETE 或 ON_UPDATE 设置为级联时出现 MSSQL 错误。

任何建议，或者这是应该如何完成？顺便说一下，也欢迎任何有关命名约定等的建议（也许作为评论）。

谢谢，
卢克

编辑：更改了标题，希望能更清楚。前一个更全面，但可能过于复杂。

Answer 1

你建模的方式很好。您的模型确保业务规则由数据库强制执行。

作为替代方案，您可以做几件事。一种方法是消除 上的代理键Roles_Applications。作为交集表，您可以将两个外键一起用作复合主键。如果你这样做了，它就会传播Role到Application你的桌子上Applications_Permissions_Roles。这样做的优点是可以为您的应用程序权限数据提供更多的“一站式服务”（即更少的连接），而不会以任何方式影响您的规范化。

您可以采用的另一种方法是稍微简化并为每个应用程序定义默认权限。您可以将其称为任何您喜欢的名称，例如“默认访问”或“基本访问”或“用户”或任何对您有意义的名称。这将允许您展平模型并基本上删除表格Roles_Applications并Applications_Permissions_Roles直接连接到Roles. 这将改变您用来询问“哪些角色可以访问哪些应用程序？”的查询的性质。但您的业务规则仍将由架构强制执行。