mysql - 数据库设计 : Is it okay for a table to have half-related records?

Question

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

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

但有时bar是独立存在的，与foo无关。

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

更新:

我会尽量不那么抽象。

假设我有一个checkout 和email 表。有时我可以发送与结帐无关的电子邮件，但通常结帐会附加到特定电子邮件。

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

这是我能找到的最接近真实示例的地方。

Answer 1

特化

通常为实现这一目标而做的一件事称为特化，这意味着您会将表拆分为多个相关的表，如下所示:让我们只看下图的右侧.有两个实体“SALARIED_EMPLOYEE”和“HOURLY_EMPLOYEE”都与“EMPLOYEE”相关。这意味着可以按小时或按月(固定工资)向员工支付工资，并且根据支付类型，该用户将在不同的表中有一条记录。

当存在(如图所示)多种类型的某些实体(例如按小时/按月支付的员工)并且这两者有很多共同的属性(例如姓名、社会保险号、出生日期、地址)时，就完成了特化。我们说 'EMPLOYEE' 是 'SALARIED_EMPLOYEE' 和 'HOURLY_EMPLOYEE' 的父类(super class)。每当添加一名员工时，其中一个子类中也必须添加一行。

特化的另一个优势是其中一种类型可以与另一种类型具有不同的关系。在上面的示例中，只有按小时计酬的员工才能属于工会，由菱形“BELONGS_TO”可视化

应用于您的问题

在这种情况下，您可以创建电子邮件的父类(super class)，以及带有 checkout 和没有 checkout 的电子邮件的子类。这些子类可以有额外的属性，带有结帐的电子邮件可以与结帐表相关(如图所示)。

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

希望这对您有所帮助。

(图片来自 here ，这些和其他概念也在此网页上进行了解释)