用户角色数据库架构设计答案

【问题标题】：User Roles DB Schema Design用户角色数据库架构设计
【发布时间】：2012-03-08 03:47:26
【问题描述】：

我正在考虑一种涉及拥有用户和用户角色的架构设计，但我不确定哪种方式更好。

选项 1

创建三张表，一张是用户信息，一张是角色信息，一张是用户角色关系。

users {
    u_id,
    etc
}

roles {
   r_id,
   r_name,
   etc
}

user_roles {
   u_idm
   r_id
}

选项 2

创建两个表，一个包含用户信息，另一个包含角色、角色信息和关系信息。

users {
    u_id,
    etc
}

roles {
   r_id,
   u_id,
   r_name,
   etc
}

选项 1 更健壮，但需要额外的连接。选项 2 将需要一个额外的主键，但只会是一个连接。如果我更改了角色名称，则使用选项进行更新需要更长的时间，但我不认为更新会很频繁。

对于可扩展的解决方案，哪个更好？我失踪还有哪些其他见解？这是一个 mysql 和 postgresql 解决方案。

【问题讨论】：

【解决方案1】：

选项 1。如果每个角色只有一个用户可以拥有，那么一个角色有什么用？如果您有 100 个注册用户，则“注册用户”将有 100 个重复定义。

“等”越多，您的数据库就越大。

拥有如此多的重复项会减慢您的数据库速度，即使您的连接数减少，最终也会慢很多。

如果您运行大量基于角色的查询并且依赖于您需要一个类似于选项二中的数据库的数据库，您仍然可以创建一个视图并让数据库缓存它，但我怀疑这对您有什么好处。

【讨论】：

【解决方案2】：

我会选择第一个选项并进行一些更改：

- each user can belong to ONLY ONE group
- create a table defining privileges
- each group has a list of privileges

定义的权限可以映射到应用程序的各种模块或特定功能。

解决方案简单、灵活且快速。特权表和组表都应该非常小，因此额外的 JOIN 不会产生如此严重的影响。此外，经过身份验证的用户权限可以存储在会话中，而不是每次都加载。从长远来看会有更多好处，因为该解决方案非常灵活且易于扩展。

例如，您将创建一个名为“配置”的新模块，并且您希望创建一个名为“超级管理员”的新用户组，以便在任何地方都可以访问和“配置”。您只需在数据库中进行更改：创建组“超级管理员”，添加权限“配置”，设置所有权限即可。

【讨论】：