在一对一的关系中，外键应该放在哪里？
Xeg*_*ara 7 erd database-design table
我目前正在为项目管理系统设计 ERD。我无法在两个可行的解决方案之间进行选择作为最佳解决方案，因为我希望采用最佳标准。
可以访问系统的两个实体是客户和员工。由于它们具有不同的信息，我决定将它们视为不同的实体。我认为最好为系统用户使用一个表，而不是在客户和员工的两个表中都找到用户名和密码字段。另外，我必须遵循的限制：
- 所有用户仅限于员工和客户。
- 但并非所有员工都必须成为系统的用户。
以下是尚未定义关系的以下实体：
现在，用户与客户、员工与用户之间只有一对一的关系。我的问题是我应该在哪里放置外键？我是否应该在用户表中放置两个外键，即employee_id 和 client_id，这样可以更轻松地从用户实体中找到关联的客户和员工实体，并且可以更轻松地定义授权规则？或者我是否应该将每个外键放在引用用户表的客户和员工身上，因为我不确定在一个表中包含两个外键且一次只能使用一个外键的做法是否可以接受。
小智 1
首先，我想说（正如其他人指出的那样），拥有互斥的外键没有任何问题！
其次，尽管它很优雅且适用于其他场景，但我认为@Joel Brown发布的超集解决方案并不适合您的具体情况。虽然它使得处理“人”的子类型（实体、用户、你拥有的东西）变得更加容易，但听起来你的项目不会扩展到这两个群体之外。
在我看来，您可以在这里采用三种技术：
- 正如@Joel Brown所指出的，子类型/超集解决方案。
- 使用您当前拥有的三个表，在 中包含两个 FK ，或者在和表
users中的每个表中包含一个 FK 。Clientsemployees - 拥有一个
Roleanduser_role表，使用表中的用户角色users（然后将“客户”和“员工”降级为角色）。
这些选项中的每一个（正如您可能想象的那样）都有其自身的优点和缺点。
超级组：
优点
- 允许您添加任意数量的“类型”，每个类型可以根据需要拥有任意数量的不同字段。
- 允许一个“用户”同时成为客户和员工（或任何其他子类型）。
缺点
- （本质上）不允许子类型之间有任何排他性。 即，如果我们有子类型“警察”和“强盗”，则一个实体可以同时既是警察又是强盗。
- 因此（正如您在评论中提到的），很难确定特定的人/实体是什么类型。
- 不允许存在不是“实体”（或个人，或您为主表指定的任何名称）的员工。（不过，我应该指出，确实允许不是用户的员工。）
当前设计
优点
- 允许您的每个“类型”（
Clients和employees）具有所需数量的不同字段。 - 允许类型之间的排他性，即一个用户不能
user_type同时拥有Client和user。 - 允许存在不是用户的员工。
缺点
- 不会扩展到超过少数“类型”。 即，如果您不仅仅是
Clients和employees，而是 20 多种类型 - 对此的查询会变得非常慢（因为每种类型都需要用户中的新 FK）。 - 并不隐式地允许您轻松确定 a 的“类型”
user（假设您在 中使用 FK ，PK 会反转这一点）。users
用户角色
优点
- 可以扩展到数千（或数百万？）角色（因为角色是一个更简单的构造，不需要每个角色都有自己的表）。
缺点
- 不允许每个角色拥有所需数量的不同字段。（角色都具有相同的字段，很可能只不过是一个名称 - 一切都将在应用程序逻辑中决定角色的含义。）
- 不允许角色之间有任何排他性。（你可以再次同时成为警察和强盗。）
那么答案是什么呢？
好吧，角色允许大量的可扩展性，但这是以可建模的复杂性为代价的。由于其简单性，您可以拥有一千个角色，但每个角色只会告诉您很少的信息（因为角色不能拥有自己的字段）。因此，我想说角色不适合您的项目，因为您需要为员工和用户建模不同的事物。
子类型（又名超集）可能适合您的项目。然而，对于只有两种类型的系统来说，查询以确定用户类型所增加的难度可能不值得带来好处。此外，员工同时也是客户的情况可能永远不会发生。可以很安全地假设，在内部工作并为客户工作的人（如果所有相关人员都允许这样的事情），他们的每个角色（职位）都有一个单独的电子邮件/登录/身份/用户名，因此只会登录适当的帐户。
您当前的设计（在 中使用双 FK ）既允许对每种不同类型users所需的字段进行建模，又允许您拥有（理想的？）相互排他性，以防止用户既是客户又是员工。然而，它确实存在一个问题，即很难（仅从一个）知道要查询该用户的哪个表（即该用户是客户还是员工）。users id
为了解决这个问题（如果你特别关心），我建议添加一个字段users来表示类型。从字面上看，这可能类似于user_kind, 具有enum(client,employee)类型。如果您想变得更高级，您可以将该字段和user_type第四个表都提取出来，该表有一个 FK backusers和相同的双 FK（on user_type）到Clients和employees。