数据库设计：OR关系

我有一个包含关于我的用户数据的“用户”表的数据库。每个用户都将被链接到一家公司或大学。我希望有两个独立的表格“大学”和“公司”，每个都有一个“ID”字段。那么如何将用户表中的每条记录链接到公司或大学？数据库设计：OR关系

最基本的是我希望在数据库中建立一个“或”关系。

2010-05-24 Ant

我会创建关系表。 UserCollege和UserCompany。这样，如果将来需要，您甚至可以让用户链接到两者。如果没有，你只是简单地对一个创建relationrecord两个

2010-05-24 06:33:16 KroaX

号如果你想，在未来涉及一个人到两个大学和公司，你只需要改变在组织用户关系（上达米尔的模型），以多对多的。 – 2010-05-24 17:29:35

你可以使用一个“机构”或“组织”的查找表，具有结构类似

InstitutionId[PK], InstitutionType, LookupKey

其中LookupKey是PK要么公司或学院。

或者，

InstitutionId[PK], CompanyId[FK], CollegeId[FK]

在您从用户链接到机构这两种情况下，然后到公司和/或学院。

我个人更喜欢第二种选择，因为它允许您轻松验证FK关系，并且还允许（如果适用）用户成为公司和/或大学的成员。

2010-05-24 06:34:50

虽然第一个解决方案似乎在'OR'关系中更严格，但作者是正确的，宁愿选择第二个选项。具有多重意义的一列通常是不好的设计，并且在将来不会很有扩展性（例如：添加了另一个含义，但旧应用程序不知道它并需要修改） – Konerak 2010-05-24 06:57:03

+1我同意本和Konerak的偏好 - I '从来不提倡解决方案＃1，这将导致随着时间的推移数据混乱。解决方案＃2工作正常，而且它是唯一真正以此为目标的“安全”方式。 – 2010-05-24 07:12:41

您可以使用子类型/超类型关系。保留组织表中的所有常见字段。学院和公司表只包含特定于这些实体的字段。

2010-05-24 14:33:52

这比Ben Hughes IMO的两个设计更好。如果再添加一个表格，则不必像第二个选项那样创建另一个FK列，并且不需要多重意义，因为Konerak在第一个列表中正确地进行了批评。 – user37078 2010-05-24 14:51:43

我不熟悉这种表示法。它看起来结合了逻辑数据建模和物理的元素。 @Ant，请记住，在像这样的逻辑数据模型中，OrgType继承可能在物理上表现为Org表中的指定属性（OrgType列）。 – 2010-05-24 17:32:17

@Stephanie;该图非常物理:) OrganizationType只是一个类别分类器列。请参阅您的ERD工具中的类别符号。 – 2010-05-25 13:55:00

回答