Question

我正在考虑涉及拥有用户和用户角色的架构设计，但我不确定什么是更好的路径。

选项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解决方案。

Answer 1

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

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

拥有那么多重复数据会降低你的数据库速度，最终即使你少了一个连接，事情也会慢得多。

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

Answer 2

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

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

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

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

例如，您将创建一个名为“Configuration”的新模块，并且您希望创建一个名为“superadmin”的新用户组，以便随处访问和“配置”。您只需在数据库中进行更改：创建组'superadmin'，添加权限'配置'，设置所有权限，就是这样。