Лучший способ создать эти таблицы

Question

Часть моей схемы для туристического проекта имеет следующие таблицы

Cruises
Flights
Hotels
CarParking

Мне нужен контейнер, который упаковывает один или несколько из этих продуктов в пакет.Один круиз / отель и т. Д. Может быть частью многих пакетов.Сначала я думал о

Package
- PackageId
- Etc

PackageItem
- PackageItemId
- PackageId (fk)
- ItemId (fk)
- ItemType

Где ItemType будет указывать, является ли это круизом, рейсом, гостиницей и т. Д. Я полагаю, я мог бы использовать триггеры для обеспечения ссылочной целостности.

Моя другая идея была

Package
- ...

PackageItem
- PackageItemId
- PackageId (fk)
- CruiseId (nullable fk)
- FlightId (nullable fk)
- HotelId (nullable fk)
- CarParkingId (nullable fk)
- etc

Полагаю, у каждого есть свои плюсы и минусы, но я не могу решить.Как вы думаете, что лучше, что бы вы выбрали, если бы вам пришлось реализовать что-то вроде этого?

База данных - это MySql.Платформа - C # MVC ASP.NET

(я искал, и было несколько похожих вопросов, но ничего, что так хорошо соответствовало)

Answer 1

Первый вариант самый гибкий.И я склонен идти с гибкостью.

Преимущество: общие запросы

Если вам нужен отчет о круизах, запрос такой же, как и для отелей, но с другим предложением WHERE.

Используя вторую форму, вам нужно присоединиться и выбрать из разных таблиц.

* Преимущество: рост без изменений схемы

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

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

Стоимость: перемещение данных в форму, не благоприятную для пищеварения человека

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

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

Недопустимость: ограничения не могут быть применены

Ограничение - каждый компонент пакета должен быть либо Отель, Упаковка, Полет или Круиз
Метод - Есть таблица component_typeи FK для этой таблицы

Ограничение - для каждого пакета разрешен только один из каждого типа
Метод - УНИКАЛЬНОЕ ограничение для (package_id, component_type_id)

Ограничение - каждый компонент может быть только в пределах одногоМетод пакета - УНИКАЛЬНОЕ ограничение на (component_id)

Стоимость - отложенная сложность

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

Одна глобальная таблица «компонент» может содержать все поля, но позволяет им обнуляться.Таким образом, HOTEL будет иметь NULL Flight_Number.Но все компоненты будут иметь цену.

Или вы можете создать таблицу Entity_Attribute_Value.Это может быть сформировано таким образом, чтобы отели не имели номер рейса ...
- component_attributes table = (id, type_id, attribute_id, attribute_value)
- (type_id, attribute_id) может иметь внешний ключ для допустимогокомбинации

Невозможно (afaik) применить обязательные поля, такие как Price.
Значение часто сохраняется как VARCHAR.
По этой и другим причинам поиск данных по значению становится трудным,

окончательное мнение

Я бы не использовал вариант 2, поскольку он сильно ограничен и объединяет два соображения вместе - Как хранить данные для разныхтипы компонентов (отели, рейсы и т. д.) и как связать их с родительскими пакетами.

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

Answer 2

Вы не упомянули вопрос о том, нужно ли поддерживать несколько продуктов одного типа в одном пакете, например, может ли пакет содержать несколько отелей.

1) Если поддержка нескольких одинаковыхТип продуктов в упаковке необходим, тогда вам следует идти первым путем, но, возможно, разделите отношения на отдельные таблицы для каждого типа продукта, т.е.

PackageHotelItem
- PackageItemId
- PackageId (fk)
- HotelId (fk)

PackageCruiseItem
- PackageItemId
- PackageId (fk)
- CruiseId (fk)

... etc.

Таким образом, вы сможете иметь ссылочную целостность с помощью обычного механизма FK.

2) Если вам не нужна такая поддержка, вы можете воспользоваться вторым решением.