如何有效地将列表建模到不同的实体？

Question

鉴于以下模型：

CustomerType1(id, telephone, address)
CustomerType2(id, telephone, name)

OrderType1(id, timestamp, customerType1.id, comments, enum1)
OrderType2(id, timestamp, customerType2.id, comments)
OrderType3(id, timestamp, name)

我如何建模以下内容？

OrderList(id, OrderType.id, ..)
OrderItem(OrderList.id, MenuItem.id)

一个。我是否需要3种不同类型的OrderLists才能适应orderTypes？

OrderList1(id, OrderType1.id, ..)
OrderItem1(OrderList1.id, MenuItem.id)

OrderList2(id, OrderType2.id, ..)
OrderItem2(OrderList2.id, MenuItem.id)

OrderList3(id, OrderType3.id, ..)
OrderItem3(OrderList3.id, MenuItem.id)

或

B中。 orderLists和OrderTypes之间关系的3个定义会更好吗？

OrderList_Type1(orderList.id, orderType1.id)
OrderList_Type2(orderList.id, orderType2.id)
OrderList_Type3(orderList.id, orderType3.id)

这似乎是一种非常低效的存储数据的方式，我只是觉得我已经非常错误地建模（尽管它仍然有意义，它可能不适合扩展/效率？）。有没有更好的方法来模拟这个？

注意：可以更改给定的模型，但仍然必须包含相同的信息。

Answer 1

1。你的UML模型没问题

从UML类图的角度来看，您想要添加的模型和OrderList，OrderItem扩展是清晰明确的，我没有看到任何建模问题。

为了避免过多的复制/粘贴，我只添加了2个名为...Base的父类。这是常见的OOP建模技术

绘制为UML类图，您的模型如下所示：

2。对于物理实现，我会选择B

关于此模型的实施“模型”来自您给出的两个选项（（A）许多复制/粘贴，（B）以某种方式{{3}我会去下面绘制的（B）路径。

这是我们公司的一个软件系统如何在关系语言中模拟类继承，它的工作原理很好。

在我们的系统中，大多数必要的胶水代码都是自动生成的。主要是自动生成的OrderType2View，它自动连接父表OrderTypeBase中的相应字段，并自动转换所有DML操作，例如在OrderType2和OrderTypeBase中插入DML操作会自动将正确的OrderTypeClassId字段添加到父表中的所有记录中。因此很容易区分哪个子表实际上包含记录的特定部分。

由于生成器，我们可以轻松地使用其他父类扩展模型（继承层次结构和连接表的数量可以是任何深度），并且仍然允许一些旧代码将它们视为一般父母 - 而不关心细节。

我不知道是否有更好的方法，鉴于（A）或（B）我会选择（B），因为它是一个有效的设计（我见过它:)