一个帐户的分组用户的数据库设计答案

【问题标题】：Database design for grouped users with one account一个帐户的分组用户的数据库设计
【发布时间】：2014-05-26 01:19:21
【问题描述】：

（基于Web的应用场景）

我正在尝试解决以下条件的问题：

现在。我对下一个条件感到困惑

帐户是按家庭而非每个患者发放的。同一个家庭的患者使用相同的用户名和密码。如果我将用户名和密码属性放在家庭中，我还必须为员工输入用户名和密码。我被告知我应该始终避免表中的冗余。我真的很难为最后一个条件构建一个表。

我怎样才能做到这一点？我应该创建一个名为 Account 并具有属性（id、用户名、密码）的表，并让它作为外键被家庭表和员工表引用吗？

或

我是否应该使用属性（id、用户名、密码、staff_id、family_id、类型）创建一个名为 Account 的表。在这个设计中，我真的不确定它是否是一个好的设计，因为staff_id 或family_id 之间的一个属性将为null，它总是会返回一个约束，因为引用的父表没有值。

或者有没有更好的方法可以做到这一点，而我的任何选择都没有？

任何帮助将不胜感激。

【问题讨论】：

【解决方案1】：

有人告诉我，我应该始终避免表中的冗余。

你学得很好。

创建密码表。

Password
--------
User ID
Password
Account or Staff value
Account or Staff ID

密码必须加盐和加密。该值告诉您 ID 是用于具有家庭权限的帐户还是具有工作人员权限的工作人员。

如果你需要两个以上的值，你应该创建一个 Value 类。

Value
-----
Value ID
Value Name

也许还有一个值权限类。

Value Permission
----------------
Value ID
Permission ID

Permission
----------
Permission ID
Permission

这可能对您的应用程序来说太细了。

记住。您可以创建数千个表，只要每个表包含与键、整个键相关的值，并且只包含键，所以请帮助您 Codd。

【讨论】：

感谢@Gilbert 指出密码应该加密和加盐。我将添加一个额外的表“帐户”来存储用户名，然后我将引用 password_id
如果密码表的主键是user_id。如果用户是家庭成员怎么办（注册另一个具有相同姓氏的用户的条件）。我想我会遇到一个问题。将帐户 ID 引用到用户表是否会更好？在这种情况下，用户的每个帐户都可以通过帐户 id 来标识
@MLDS：我以为这个家庭只有一个用户 ID。如果它被称为帐户 ID，那就这样吧。

【解决方案2】：

当您不确定什么是处理定义不明确或潜在流动性需求的最佳数据库结构时，最好的经验法则是将每个感兴趣的事物（无论是有形的还是无形的）都视为一个实体/表。

在您的情况下，您有帐户。一些帐户分配给员工。一些帐户分配给家庭。也许将来家庭帐户可能会分配给其他类型的个人或团体？无论如何，一个帐户总是具有某些稳定的属性，例如用户 ID 和密码。因此制作一个帐户表。

然后您需要弄清楚如何将您的其他实体与帐户相关联。我想你会很快发现你希望你的家庭表和员工表指向帐户，而不是相反。这才是最有意义的。至少在您的老板告诉您允许每个员工或家庭拥有多个帐户的新要求之前...

【讨论】：

抱歉在这里有点困惑。我只是想澄清一下，您的意思是我的家庭表和员工表应该包含引用他们帐户的外键 account_id 吗？而且，我有一个包含他们详细信息的用户表。将帐户表连接到用户表会更好吗？
@MLDS - 是的，每个家庭和员工表上都有account_id。至于USER 表与ACCOUNT 表，请仔细考虑您是否真的做出了区分。一个真实的人（用户）可能会开设许多帐户。但是，您的组织真的想要区分真实的人和他们的登录名吗？我发现大多数组织真的不关心人（从数据库的角度来看）。我参与的大多数地方实际上都停留在登录 ID 上。您可能希望将 USER 和 ACCOUNT 合并到一个表中。
原来我就是这么做的。但为了符合要求，并不是每个患者都有一个帐户。如果他们属于一个家庭组，他们将拥有相同的帐户。
@MLDS - 有时名称只是语义，但有时语义很重要。您可能会发现 USER 是您想要避免的东西。也许您应该有一个 PATIENT 表和一个 ACCOUNT 表。这可能有助于将有血有肉的人的概念与用户 ID/密码组合区分开来。它不会改变你的结构，但它可以帮助你记住哪些列属于哪些表以及你的关系（外键）应该去哪里。