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

我正在为以下情况创建数据库方案：

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

假设没有高性能环境（无需针对速度进行优化），那么实现此架构的最佳方法是什么？数据库环境可以是MySQL，MSSQL ...更多是关于关系数据库的设计。

我本人提出以下建议：

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

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

有什么建议，或者这是应该怎么做的？也欢迎任何其他有关命名约定的建议（例如作为评论）。

谢谢，
卢克

编辑：更改标题，希望使其更清晰。前一个比较全面，但可能太复杂了。

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

您可以做几件事作为替代。一种是消除上的代理键Roles_Applications。作为相交表，您可以将两个外键一起用作复合主键。如果这样做，它将传播Role并向Application下传播到Applications_Permissions_Roles表中。这样的好处是可以为您的应用程序许可数据提供更多的“一站式服务”（即更少的联接），而不会以任何方式损害您的规范化。

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

Roles_Application在这里似乎并不代表真品。这是什么意思，除了表示特定角色对应用程序具有一定级别的权限外，即使您需要签出Applications_Permissions_Roles确定该级别是什么级别，又意味着什么？举例来说，这是一个CEO可以在当前模型中对应用程序Calendar进行写访问：

的角色

ID    Name
--    ----
1     CEO

应用领域

ID    Name
--    ----
C     Calendar

权限

ID    Application_ID  Permission
--    --------------  ----------
10    C               Write

角色_应用

ID    Role_ID    Application_ID
--    -------    --------------
50    1          C

Applications_Permissions_Roles

Role_Application_ID    Permission_ID
-------------------    -------------
50                     10

我认为可以在没有的情况下对这一系列关系进行建模Roles_Applications。如果我们将其删除（如乔尔·布朗建议的那样，但不作更改，即假设存在“默认权限”）：

的角色

ID    Name
--    ----
1     CEO

应用领域

ID    Name
--    ----
C     Calendar

Applications_Permissions（nee Permissions）

ID    Application_ID  Permission
--    --------------  ----------
10    C               Write

Applications_Permissions_Roles

Role_ID    Application_Permission_ID
-------    -------------
1          10

旧Permissions表没有简单的权限，例如“读取”和“写入”，然后可以将其应用于“ Topdesk”和“ Calendar”之类的应用程序：它包含特定于应用程序的权限，例如“在Topdesk中写入”和“在日历中写入”和“在Windows中更改系统时钟”。为了更清楚一点，我已经命名了表格，Applications_Permissions但是当然这不是必需的步骤。

与Joel的第二个建议一样，这种方法具有使模型扁平化的效果，但是没有添加应用程序逻辑或默认权限的概念。 Roles_Applications除了表明角色可以对应用程序进行某种程度的访问外，其他任何事情都没有带来。通过Applications_Permissions_Roles使用适当的Role_ID值的记录的存在，可以更简短地传达该信息。