更多关于继承＆amp;数据库设计

Question

前言：虽然我认为这并不完全重复，但如果您认为这与this previous question from me太相似，请随时关闭。

我正在重新设计一个数据库设计，我有四个超类表，其他一些必须从中派生出来。现在，我怀疑是否应该包括（四）“类型识别”表并将它们连接到每个超类，以便识别每个记录的子类型。问题在于，如果没有它们，设计已经相当大（14个表），并且由于其中一个要求必须易于扩展，我担心最终会有30个或更多的表设计。简而言之......这种类型的表可以/可以不在设计之外吗？

PS：目标是拥有一个高度且易于扩展的设计。例如，其中一个表代表消息，其子类型可以是SMS，MMS，电子邮件， twit ，上的帖子> Facebook 等。当然，常见信息在超类上，其余信息根据需要进入其他几个表。

Answer 1

理解30个表比30,000行代码更容易。我曾经使用过包含100多个表的数据库。我不担心30.

用于捕获分组为超类和多个子类的实体的表的设计是gen-spec设计模式的一个示例。通过类继承，面向对象程序员熟悉Gen-spec。但是，从介绍性文本到数据库设计中，往往忽略了反映gen-spec模式的关系表的设计。

幸运的是，这是很好理解的。关于“泛化专业化关系建模”的网络搜索将产生大量关于该主题的文章，包括之前的几个SO讨论。

正如您所说，所有专业实体共有的数据都在一般（超类）表中，而给定专门实体所特有的数据则在适当的专用（子类）表中。

设计中的技巧是子类表获取主键的方式。子类表的主键不是自动增加的数字。它是超类表中PK的副本。这样，只需进行连接即可轻松获得有关特定专业的所有数据。它还使得不必包含类型字段，因为每个专用表都包含它自己的子类。

这有点难以设置和更新，但它在检索时付出了代价。

Answer 2

一切都取决于要求。
在不知道数据库要求的情况下，无法判断14表是否很多 关于衍生品。一个问题你应该问自己“对所有消息的操作是否相对于特定类型消息的操作是一项常见任务？”。如果答案是肯定的，那么你应该使用派生方法，否则最好有不同的表（短信，电子邮件等），其中一些字段共享一个共同的名称。
关于实施。如果您熟悉ERD（一种可视化数据库的好方法）IS-A关系，那么实现它的常用方法如下。消息表将包含所有消息共有的所有字段，无论其类型如何。每种消息类型都有一个表，它将包含特定于此消息类型的字段。这需要加入一些查询。
我相信这就是你在问题中的意思。如果是这样，这就是我认为最好的方式。

Answer 3

一种方法可能是围绕properties pattern设计数据库。因此，您可以拥有一个包含所有常见超类字段的Messages表，以及一个允许将任意属性添加到任何MessageProperties实例的Message表。

在这种情况下，如果Message具有特定于该类型的属性（例如，可能是SMSMessage属性），则destinationPhoneNumber是Message。这使得服务器端代码中的更多工作可以区分不同的对象类型，但它允许您仅使用两个表来拥有任意数量的不同{{1}}“子类”。