数据库设计的抽象/超类/子类结构

Question

我已经在这个墙上撞了几次头。因此，我希望在正确的方向上提供一些帮助。

我有一张ORDERS表，一张有TRAINS，一张有FLIGHTS，另一张有BUSES。每个订单都应该有单一的运输方式。到目前为止，我的设计包括ORDERS表格中的一个字段，说明了运输的类型（火车，飞行，公共汽车）以及包含所述运输类型的forreign钥匙的字段。

有没有更好的方法呢？

Answer 1

我在这个主题中看到的最好的描述是在Craig Larman的书“应用UML和模式”中 - 虽然他是从面向对象而不是数据库的角度来写的。

关系世界有三种选择（这是基于拉曼的书）：

每个变体
• 子类型。因此，您创建了一个“order_flight”表 航空公司，座位选择等，以及与from_station的“order_train”， to_station等。这使表格保持良好和自我描述，但是 使你的SQL变得一团糟 - 它必须为每个子类型进行更改。
• 包含所有可能列的单个表：在这种情况下，您有一个表，其中包含所有子类型的所有可能字段。这条路， 你的SQL保持简单 - 但表格变得非常混乱，而且 你依靠你的客户申请“知道”航班有 航空公司，但火车没有。
• 用于公共属性的表，子类型在其自己的表中存储其唯一值。这基本上就是你所选择的 日期;关系可以在“订单”表中设置，也可以在 子类表。

每个选项都有优点和缺点 - 特别是在你事先不知道你需要哪种子类型的情况下，第一个选项是数据库端最简单，但是会造成一些混乱客户代码。

Answer 2

如果所有项目都具有对象结构和子类型 - 超类型关系，则可以使用相同的父对象Id。不要像对待树模型那样对待它们。 This thread shows an example

如果您使用的是面向对象的建模，您也可以在数据库中使用面向对象的结构。因此，如果要扩展类，则还要扩展数据行，将它们连接到相同的ID号。这就是为什么我说“为超类型和子类型使用相同的id，因为你想加入超类型和子类型来创建一个子类型对象。