用于处理用户门户和客户网站的架构中的单个用户表答案

【问题标题】：Single user table for in schema which process user portal and customer website用于处理用户门户和客户网站的架构中的单个用户表
【发布时间】：2017-08-12 21:27:43
【问题描述】：

我们正在为 REST 应用服务器运行单个数据库。我们有三种类型的用户

为客户
对于管理员和
对于合作伙伴

目前他们有不同的表，用户名和密码也分别分开现在我们需要在用户扩展时重构这个模式。那么单个表User 和Role 表应该可以吗？（此处Role 可以是管理员、合作伙伴或客户、经理）。

或

如果我们使用用户和角色表，我们是否应该保持原样我们将遇到问题：

如果管理员获取用户名，则由于唯一性限制，该用户名对于客户或合作伙伴不能再次相同。
我认为用户角色不能是“客户”，因为客户不是角色。角色可以是管理员、经理等

我认为这不是保持单表的正确方法。你有什么建议？

【问题讨论】：

标签： database database-design architecture

【解决方案1】：

我认为您应该为您的用户管理创建三个表，考虑到一个用户可以具有多个角色的事实（例如：- 管理员也可以是经理，或者客户也可以是合作伙伴）。所以 User 表和 Role 表是多对多的关系。为了创建这种关系，您必须创建以 userId 和 roleId 作为复合主键的第三个表。

此外，我注意到您要将用户的密码保存在数据库中。出于安全原因，请勿以纯文本形式存储密码。 Instaed 使用单向散列算法存储密码的散列。您可以从这里阅读更多相关信息 -> Best way to store password in database

【讨论】：

不，我们正在使用 BCrypt 保存密码。但问题是制作一个角色为用户管理员或客户或合作伙伴的单个表可以获得相同的用户名。我们也在进行社交网络登录，因此他们可以针对 userId 使用相同的社交网络 ID（fb 或 gmail）。由于管理它们，我们将陷入困境。
对于任何表格设计，尽量使用数字主键。在这种情况下，使用自动递增用户 ID 作为用户表的主键。要唯一识别用户，请在注册用户时收集用户电子邮件地址。因此，当您使用社交登录时，您无需担心与其他用户发生冲突。首次使用社交登录时，请记住将用户详细信息添加到数据库中。
你没有明白这个答案背后的想法。您有一个表，其中包含所有用户登录作为密码哈希（和其他详细信息），但没有有关其角色的信息（称为用户）。无论特定用户实际拥有多少规则，它都会为每个用户提供一个条目。然后是一个列出所有可能角色的表格（称为角色）。此处只有 3 行：1 行用于客户，1 行用于管理员，1 行用于合作伙伴。然后你有第三个表，它通知哪个用户具有哪个角色，并且同一用户可能在那里分配了多个角色。
另请注意，这是可能的解决方案之一。这在很大程度上取决于所采取的要求和假设。

【解决方案2】：

用户
身份证
用户ID
角色（外键）
等等。

角色
身份证
名称
等

上述结构是最佳实践。如果您确实需要管理员、合作伙伴或客户的额外字段您可以为每个实体创建单独的实体，您可以将用户作为外键引用，如下所示

客户
身份证
名称
用户（外键）
等

【讨论】：

我将把用户名和密码保存在哪里？只在用户表中？
@JohnnyMartin，是的，您可以将用户名和密码（加密）保存在用户表本身中。
根据您的设计，用户不能有很多角色，但无论如何都对我有用，因为我们只有一个角色。但我会将角色设置为 user_type 表，这样任何人都可以理解用户是单一类型的。

【解决方案3】：

是的，最好保留单独的表格，原因如下：
1. 正如您所指定的，客户不是角色。
2. 由于管理员数量有限，从拥有客户的大型数据集中获取用于身份验证/授权的记录是没有意义的。这会阻碍性能。

【讨论】：