前言：虽然我不认为它完全是重复的，但如果您认为这与 this previous question from me 过于相似，请随时关闭。
我正在重构一个数据库设计，其中我有四个 超类 表，其他一些表必须从中派生。现在，我面临是否应该包括（四个）“类型识别”表并将它们连接到每个超类的疑问，以便识别每个记录的子类型。问题是，如果没有它们，设计已经相当大（14 个表），并且由于其中一个要求是必须易于扩展，我担心最终会得到 30 个或更多表的设计。简而言之……这种类型的表格可以/可以不被设计出来吗？
PS：我们的目标是拥有一个高度且易于扩展的设计。例如，其中一张表表示message，其子类型可以是短信、彩信、电子邮件、twit、上的帖子>Facebook 等等。当然，公共信息放在超类上，其余信息根据需要放在其他几个表中。
【问题讨论】：
标签： database-design inheritance
30 个表格比 30,000 行代码更容易理解。我使用过包含 100 多个表的数据库。我不会担心 30 岁。
设计表来捕获分组到一个超类和几个子类中的实体是 gen-spec 设计模式的一个示例。 Gen-spec 通过类继承为面向对象的程序员所熟悉。但是，在数据库设计的介绍性文本中，经常会省略反映 gen-spec 模式的关系表设计。
幸运的是，它很好理解。对“泛化专业化关系建模”的网络搜索将产生大量关于该主题的文章，包括之前的几个 SO 讨论。
正如您所说，所有专业实体共有的数据放在通用（超类）表中，而给定专业实体特有的数据放在适当的专业（子类）表中。
设计中的技巧是子类表获取主键的方式。子类表的主键不是自动递增的数字。它是超类表中 PK 的副本。这使得只需进行连接即可轻松获取有关给定专业的所有数据。它还使得不必包含类型字段，因为每个专用表都包含其自己的子类。
这有点难以设置和更新，但在检索时它会收回成本。
【讨论】：
一切都取决于要求。
在不知道数据库要求的情况下，无法判断 14 个表是否很多
关于导数。您应该问自己一个问题：“相对于对特定类型消息的操作，对所有消息的操作是否是一项常见任务？”。如果答案是肯定的，那么您应该使用派生方法，否则最好使用不同的表（短信、电子邮件等），其中一些字段共享一个通用名称。
关于实施。如果您熟悉ERD 的（一种可视化数据库的好方法）IS-A 关系，那么实现它的常用方法如下。消息表将包含所有消息共有的所有字段，无论其类型如何。每种消息类型都有一个表格，其中包含特定于该消息类型的字段。这将需要加入一些查询。
我相信这就是您在问题中的意思。如果是这样，这是我认为最好的方式。
【讨论】：
一种方法可能是围绕properties pattern 设计您的数据库。因此，您可以拥有一个包含所有公共超类字段的Messages 表，以及一个允许将任意属性添加到任何Message 实例的MessageProperties 表。
在这种情况下，如果Message 具有特定于该类型的属性（例如可能是destinationPhoneNumber 属性），那么它就是SMSMessage。这使得服务器端代码需要更多的工作来区分不同的对象类型，但它允许您仅使用两个表就拥有任意数量的不同Message“子类”。
【讨论】：