我们正在为休息应用服务器运行单个数据库。我们有三个类型的用户处理用户门户和客户网站的架构中的单用户表
目前，他们有不同的表和用户名和密码也是分开的分别，现在我们需要在用户扩展时重构此架构。 所以应该单表User与Role表是OK？ （这里Role可以是管理员，合作伙伴或客户，经理）。
OR
我们一要保持，因为它是我们，如果我们使用用户和角色表将有问题：
我认为这是不正确的方式来保持单表。你有什么建议？
是的，由于以下原因，最好保留单独的表格：
1.如您所述，客户不是角色。
2.由于管理员数量有限，从拥有客户的大型数据集中获取认证/授权记录没有意义。它会阻碍表演。
用户
ID
用户id
作用（外键）
等。
角色
ID
名
等
上述结构是最好的PRACTIC即 如果你真的需要管理，合作伙伴或客户额外的字段 你可以为每一个创建单独的实体，您可以参考用户像如下
客户
ID
名
外键用户（外键）
等
我认为你应该为你的用户管理创建三张表，考虑到一个用户可以有多个角色（例如： - admin也可以是管理员或Custo mer也可以是合作伙伴）。所以用户表和角色表具有多对多的关系。为了创建这种关系，您必须创建第三个表，其中userId和roleId作为复合主键。
另外，我注意到你要将用户的密码保存在数据库中。出于安全原因，不要以纯文本格式存储密码。 Instaed使用单向散列算法存储密码的散列。 你可以从这里阅读更多关于它 - >Best way to store password in database
不，我们正在使用BCrypt保存密码。但是问题在于用户admin或者客户或合作伙伴可以获取相同的用户名，并以角色创建单个表。我们也在进行社交网络登录，因此他们可以针对userId具有相同的社交网络ID（fb或gmail）。由于管理他们，我们将陷入困境。 –
对于任何表格设计，请尝试使用数字主键。在这种情况下，使用自动增加用户ID作为用户表的主键。要唯一标识用户，请在注册用户时收集用户的电子邮件地址。因此，当您使用社交登录时，您无需担心与其他用户发生冲突。请记住在第一次使用社交登录时将用户详细信息添加到数据库中。 –
你没有理解这个答案背后的想法。你有一个包含所有用户登录的表作为密码散列（和其他细节），但没有关于它们的角色的信息（称为用户）。无论特定用户实际拥有多少规则，每个用户都有一个条目。然后列出所有可能的角色（称为角色）。这里只有3行：一个用于客户，一个用于管理员，另一个用于合作伙伴。然后你有第三个表，告诉哪个用户具有哪个角色，同一个用户可能有多个角色分配到那里。 – Ister
在哪里我会保持用户名和密码？只在用户表中？ –
@JohnnyMartin，是的，你可以在用户表本身保存用户名和密码（加密）。 –
根据你的设计用户不能有很多角色，但无论如何我为我工作，因为我们有一个角色。但相反，角色我会让它的user_type表，以便任何人都可以了解该用户是单一类型。 –