mysql - 多态关系与每种类型的单独表

Question

我正在使用具有某些类型(例如User，Appointment，Task等)的数据库，每种类型可以具有零个或多个Notes。

我为实现这些关系而遇到的可能解决方案是:

多态关系

每种类型的单独表

多态关系

许多人建议这是遵循Active Record模式的最简单的解决方案，并且似乎是最常见的框架实现，我将添加一个表，其数据为 morphable:



我的 notable_type将允许我区分 User所涉及的类型( Appointment， Task， Note)，而 notable_id将允许我获取相关 type表中的单个 type记录。

专业人士:

易于扩展，可以与多态类

轻松关联更多模型

限制表膨胀

生成一个可以被许多其他类(DRY)使用的类

CONS

随着数据的增长，更多类型的查询可以使查询更加困难和昂贵

不能有外键

缺乏数据一致性

每种类型都有单独的表格

或者，我可以为每种类型创建一个表，该表仅负责与该类型相关联的 Notes。 type_id外键将允许我快速获取单个 type记录。



在线上许多人都将其视为一种代码味道，许多文章主张避免使用多态关系，而选择另一种关系(例如 here和 here)。

专业人士:

允许我们有效地使用外键

高效的数据查询

保持数据一致性

缺点:

由于每种类型都需要单独的表

，因此增加了表膨胀

多个类的结果，每个类代表单独的type_notes表

念头

多态关系肯定是两个选项中较容易实现的一种，但是缺少外键约束，因此潜在的一致性问题让人感到不对。

带有外键的每个 notes关系表( user_notes， task_notes等)似乎是正确的方式(与设计模式保持一致)，但可能会导致很多表(添加其他可能具有 types的 notes或添加类似于 notes的类型的表[例如 events])。

感觉我的选择是简化表结构但放弃外键并增加查询开销，或者增加具有相同结构但简化查询并允许外键的表的数量。

考虑到我的情况，以上哪种更合适，或者我应该考虑替代方法吗？

Answer 1

什么是“餐 table 膨胀”？您担心表格过多吗？我正在研究的许多现实世界数据库都具有100到200个表，因为这就是需要的。

如果您要添加多个表，那么为什么要为User，Appointment和Task设置单独的表呢？如果您具有User的多值属性(例如，每个用户多个电话号码)，那么您将为电话创建一个单独的表，还是尝试以某种方式将它们全部合并到用户表中？还是具有用于用户电话，约会受邀者和任务里程碑的多态“属于其他事物的事物”表？

答:不，您将创建一个Phone表，并使用它仅引用User表。如果约会有受邀者，则会获得其自己的表(约会与用户之间可能是多对多)。如果任务具有里程碑，那也将获得自己的表。

正确的做法是像对应用程序中的对象类型进行建模一样，对数据库表进行建模。您可能想读一本类似SQL and Relational Theory: How to Write Accurate SQL Code 3rd Edition by C. J. Date的书，以了解有关表如何与类型相似的更多信息。

您已经本能地知道不能创建外键这一事实是一个危险信号。外键必须恰好引用一个父表。这应该是一个提示，即构造多态外键不是有效的关系数据库设计。一旦开始将表及其属性视为具体类型(如SQL和关系理论中所述)，这将变得显而易见。

如果必须创建一个注释表，则可以使其引用一个称为“Notable”的表，该表类似于User，Appointment和Task的父类(super class)。然后，这三个表中的每个表还将引用Notable的主键。这模仿了多态性的面向对象结构，您可以在其中拥有一个类Note可以通过其父类(super class)类型对对象进行引用。

但是恕我直言，这比需要的要复杂。我只是为UserNotes，AppointmentNotes和TaskNotes创建单独的表。我再也不用再拥有三个表了，这使您的代码更加清晰和可维护。