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

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

0 голосов
/ 24 января 2012

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

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

Пакет P:

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

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

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

например. (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

Сторона базы данных:

Определение

  • Activity

    Идентификатор активности, Начальная дата, Конечная дата, Цена

  • Hotel

    Идентификатор отеля, StartDate, EndDate, Цена

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

  • Package table

Идентификатор пакета, Идентификатор отеля, Идентификатор активности

  • Package-Activity price table

    Идентификатор пакета, Идентификатор активности, Цена // Идентификатор пакета и идентификатор активности служат уникальным ключом

  • Package-Hotel price table

    Идентификатор пакета, Идентификатор отеля, Цена // Идентификатор пакета и идентификатор отеля служат уникальным ключом

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

EDIT

Найдена соответствующая ссылка на производительность с объединениями: Когда и почему объединения баз данных стоят дорого?

1 Ответ

2 голосов
/ 24 января 2012

Здесь вам действительно нужно пять таблиц.

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

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

...