Абстрактная / супер / субклассоподобная структура для проектирования баз данных

Question

Я пару раз пробежал головой по стене. Поэтому я надеюсь на небольшую помощь в правильном направлении.

У меня есть таблица с ЗАКАЗАМИ, одна с ПОЕЗДАМИ, одна с ПОЛЕТАМИ и одна с АВТОБУСАМИ. Каждый заказ должен иметь один способ транспортировки. Мой дизайн до сих пор состоял из поля в таблице ORDERS с указанием типа транспорта (поезд, рейс, автобус) и поля, содержащего внешний ключ для указанного типа транспорта.

Есть ли лучший способ сделать это?

Answer 1

Лучшее описание этой темы я видел в книге Крейга Лармана «Применение UML и шаблонов», хотя он пишет не с базой данных, а с объектно-ориентированной точки зрения.

В реляционном мире есть 3 варианта (это основано на книге Лармана):

• подтип за вариант. Итак, вы создаете таблицу "order_flight" с авиакомпания, выбор места и т. д., а также "order_train" с from_station, to_station и т. д. Это делает таблицы красивыми и самоописываемыми, но превращает ваш SQL в огромный беспорядок - он должен меняться для каждого подтипа.
• одна таблица со всеми возможными столбцами: в этом случае у вас есть одна таблица со всеми возможными полями для всех подтипов. Сюда, ваш SQL остается намного проще - но таблица превращается в огромный беспорядок, и
  вы зависите от своего клиентского приложения, чтобы «знать», что рейсы имеют
  авиакомпании, но поезда нет.
• таблица общих атрибутов с подтипами, которые хранят свои уникальные значения в своих собственных таблицах. Это в основном то, что вы выбрали для Дата; связь может быть установлена ​​либо в таблице «заказ», либо в таблица подклассов.

Каждый вариант имеет свои преимущества и недостатки - особенно в ситуации, когда вы заранее не знаете, какие подтипы вам понадобятся, первый вариант является самым простым в конце базы данных, но создает некоторую путаницу для код клиента.

Answer 2

Вы можете использовать один и тот же идентификатор родительского объекта для всех элементов, если они имеют структуру объекта и отношение подтип-супертип.не относитесь к ним как к разным объектам, таким как модель дерева. Этот поток показывает пример

, если вы используете объектно-ориентированное моделирование, вы бы также использовали объектно-ориентированную структуру в базе данных.поэтому, если вы расширяете класс, вы также расширяете строку данных, объединяя их с одинаковыми номерами идентификаторов.вот почему я говорю «используйте одни и те же идентификаторы для супертипа и подтипа, потому что вы хотите объединить супертип и подтип для создания объекта подтипа.