Как эффективно моделировать список для различных объектов?

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)

A. Нужно ли мне 3 разных типа OrderList для адаптации к 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. Будут ли лучше 3 определения отношений между OrderList и OrderTypes?

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, Это обычная техника моделирования ООП

Нарисованная в виде диаграммы классов UML ваша модель выглядит следующим образом:

2. Для физической реализации я бы выбрал B

Что касается реализации "модели" этой модели из двух вариантов, которые вы дали ((A) много копий / вставок, (B) как-то нормализовать и минимизировать схему), я бы пошел по пути (B), приведенному ниже.

Это то, как одна из программных систем нашей компании моделирует наследование классов на реляционном языке, и это работает, и это работает довольно хорошо.

В нашей системе большая часть необходимого кода клея генерируется автоматически. Главное это автоматически сгенерированный OrderType2View который автоматически присоединяется к соответствующему полю из родительской таблицы OrderTypeBase и автоматически переводит все операции DML, например, вставка как операции DML в обоих OrderType2 а также OrderTypeBase автоматическое добавление правильного OrderTypeClassId поля для всех записей в родительской таблице. Таким образом, легко определить, какая дочерняя таблица на самом деле содержит конкретную часть записи.

Благодаря генератору мы можем легко расширить модель с другими родительскими классами (иерархия наследования и количество объединенных таблиц могут быть любой глубины) и при этом позволить некоторому старому коду рассматривать их как своих общих родителей - не заботясь о деталях.

Я не знаю, есть ли лучшие способы, учитывая (A) или (B), я бы выбрал (B), потому что это дизайн, который работает (я видел это:)