2013-11-12 4 views
5

Изображение показывает мой предложенный макет для части базы данных. Меня беспокоит ценовые группы и то, как они прикрепляются к [показывает] и [заказы]. Там должен быть список ценовых диапазонов (как в названиях), но одна и та же группа может иметь несколько значений, в зависимости от того, к какому шоу она привязана (стандартный билет на пятницу может составлять 10 фунтов стерлингов, где в качестве стандартного билета в субботу может быть £ 11).Макет базы данных/дизайн неэффективны

Мне просто кажется, что с этим подходом у них будет много почти идентичных данных - множество записей за билеты в 5 фунтов в [showpriceband], с той лишь разницей, что это showid.

Есть ли лучший подход к этому?

proposed database layout

+0

Есть 1 до 1 отношений между Show и ShowPriceBand? Другими словами, будет ли одно шоу в день? – Szymon

+0

Может быть любое количество шоу за один день, от 1 до многих от шоу до showpriceband – GJKH

ответ

2

Я думаю, что ваш подход является правильным. У вас есть

  • различных типов билеты
  • различных шоу

И их отношение п: п. Правильное решение для решения отношения n: n представляет собой отдельную таблицу (в вашем случае ShowPriceBand), чтобы заручиться всеми комбинациями.

2

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

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

+0

Извините, это должно быть 1 для многих. – GJKH

+0

Итак, как вы собираетесь это делать с ShowDateTime в таблице Shows? То же самое для заказов? Наверное, вы заказываете одно шоу? – Szymon

+0

У шоу может быть несколько ценовых диапазонов и несколько заказов, в заказе и ценовом банне может быть только одно шоу. – GJKH

2

Что касается этого вопроса:

Это только мне кажется, при таком подходе их будет много почти идентичных данных - множество записей для £ 5 билетов в [showpriceband] с той лишь разницей, иллюстративный.

Вы можете избежать этого дублирования с добавлением таблицы соединений между таблицами show и showpriceband. Я не думаю, что это было бы действительно естественно, но это зависит от ваших данных. (и, вероятно, вам также следует переименовать showpriceband ...)

Или, может быть, вы можете переместить поля из showpriceband в priceband. (value, ongeneralsale), в котором содержится немного избыточности, но при этом таблица showpriceband становится более связанной таблицей.

Смежные вопросы