как проектировать ценообразования модуля на уровне базы данных

Question

Я хочу смоделировать следующий сценарий в базе данных:

У меня есть пакет, состоящий из независимого Activities и Hotel:

пакет P:

• Деятельность A1, A2, A3
• Отель H

Activities и Hotel являются независимыми юридическими лицами, которые имеют свои собственные цены определяются на момент определения юридического лица.

Когда предприятие добавлено к упаковке, его можно изменить (только specific to the package). Следовательно, каждый пакет будет иметь уникальную цену за действия/гостиницы.

E.g. (Defining activities and hotel):

A1 - 10$ 
A2 - 20$ 

H1 - 100$ 

(Adding activities and hotel to package):

Package p; 
p.addActivity("A1", 15); 
p.addActivity("A2", 25); 
p.addHotel("H1", 50); 

yields => 

p 
- A1 - 15 
- A2 - 25 
- H1 - 50 

---

Side База данных:

Определение:

• Activity:

  Activity-идентификатор, StartDate, EndDate, Цена

• Hotel:

  Hotel-ID, StartDate, EndDate, Цена

После добавления к пакету

• Package table:

Пакет-идентификатор, Гостинично-идентификатор, активность-идентификатор

• Package-Activity price table:

  Пакет-идентификатор, активность-идентификатор, Цена // Пакет-идентификатор и идентификатор деятельности - это уникальный ключ

• Package-Hotel price table:

  Пакет-идентификатор, Hotel-идентификатор, Цена // Пакет-идентификатор и гостинично-идентификатор служит уникальным ключом

мне нужна обратная связь по дизайну, которые я придумал. Сложно ли мне это? Есть ли более простой/лучший способ сделать это? Кроме того, поскольку я писал это, я решил, что в пакете может быть много отелей и мероприятий, поэтому вам нужно будет учитывать это здесь. Разве я слишком много фрагментировал это, так как для каждого ценового поиска объекта я буду выполнять соединение?

EDIT

Нашел соответствующую ссылку на производительности с Присоединяется: When and why are database joins expensive?

Answer 1

Вы на самом деле нужны пяти таблиц здесь.

У вас есть три объекта: деятельность, гостиницы и пакеты (при условии, что в каждой упаковке есть данные, не связанные с гостиницей или деятельностью). У вас есть две связи, как многие, так и многие, а именно пакетная и пакетная деятельность. Каждая строка отношений аннотируется с определенной ценой.

Пять столов - это путь. Нет, необходимость в объединении не проблема: это лучше, чем наличие ненормальных данных. Вы можете денормализовать для производительности позднее при необходимости.