数据库设计：表是否可以拥有与半相关的记录？

Question

我有两个假设的表：foo和bar。

有时，foo可能与bar有关，所以我制作了一个foo_bar表来保存他们的ID。

但有时bar本身是孤立的，与foo无关。

这在数据库世界中不受欢迎吗？我应该为foo_isolated创建一个与foo无关的单独的bar表吗？为什么/为什么不呢？

更新：

我会尽量不那么抽象。

说我有一张checkout和email表。有时我可以发送与结账无关的电子邮件，但通常会将结帐附加到某个电子邮件中。

email表是否可以拥有checkout_email表中没有匹配记录的记录？换句话说，email表基本上是一个通用的电子邮件表，它恰好用于存储与checkout相关的记录，通过存储两个ID的checkout_email连接表。

这就像我能得到一个真实的例子一样接近。

Answer 1

Specialization

通常要做的一件事就是称为特化。这意味着您将表分成多个相关的表，如下所示：让我们只看下面图像的右侧。有两个实体'SALARIED_EMPLOYEE'和'HOURLY_EMPLOYEE'都与'EMPLOYEE'有关。这意味着员工可以按小时或每月支付（固定工资），并且根据支付类型，该用户的不同表中将有一条记录。

当存在（如图像中）多种类型的某些权利（例如，每小时/每月付费雇员）并且这两者具有许多共同属性（例如，姓名，Ssn，出生日期，地址）时，进行专业化。我们说'EMPLOYEE'是'SALARIED_EMPLOYEE'和'HOURLY_EMPLOYEE'的超类。无论何时添加员工，都必须在其中一个子类中添加一行。

专业化的另一个优点是其中一种类型可以与另一种类型具有不同的关系。在上面的示例中，只有按小时计算的员工才能属于工会，通过菱形'BELONGS_TO'可视化

Applied to your question

在这种情况下，你可以制作一个超级类的电子邮件，以及带有结帐和电子邮件的电子邮件的子类，而无需结帐。这些子类可以有其他属性，带结帐的电子邮件可以与结帐表相关（如图中所示）。

所以，正如我所说，你可以做到这一点，但在这种情况下，我认为（正如baao已经说过的那样）并不是真的有必要。当数据库扩展时，可以应用专业化的概念，您的系统现在似乎不需要这样的特定设计概念。 （专业化通常用于数据库系统中，如图像中的关系更复杂）。这篇文章提供了一般概念的一些额外背景。

希望这可以帮助。

（图片来自here，这些和其他概念也在本网页上解释）