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

Question

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

有时，foo可能与bar相关，因此我会创建一个foo_bar表来保留其ID。

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

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

更新

我会尽量不那么抽象。

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

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

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

Answer 1

专业化

通常要做的一件事就是称为专业化这意味着您将表格拆分为多个相关表格如下：让我们只看右侧下面的图片。有两个实体＆＃39; SALARIED_EMPLOYEE＆＃39;和＆＃39; HOURLY_EMPLOYEE＆＃39;这两者都与“员工”有关。这意味着员工可以按小时或每月支付（固定工资），并且根据支付类型，该用户的不同表格中会有记录。

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

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

适用于您的问题

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

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

希望这有帮助。

（来自here的图片，这些和其他概念也在此网页上说明）