создать ценовую матрицу - sql или массив констант?

Question

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

Я не определился, как лучше это сделать: либо сделать таблицу в БД дляэта матрица, или создание мега-массива констант.Проблема в том, что клиент должен иметь возможность редактировать эту матрицу, чтобы он, скорее всего, шел по маршруту базы данных.

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

Answer 1

Сделать это таблицей БД.

Единственное постоянное в ценах - это то, что они меняются.

Добавлено:

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

Ваши клиенты могут также попросить / или оценить дополнительные инструменты ценообразования, чтобы помочь им сделать все правильно.Например, ваш sw:

• может иметь отчеты, которые показывают цены способом, предназначенным для людей, занимающихся ценообразованием.
• отчет о самых высоких и самых низких ценах (допомогите отследить ошибки при вводе данных)
• Проверьте визуальный дизайн количественной информации для идей о том, как визуально показать цены для пар назначения
• убедитесь, что пара пункт назначения / отправления добавляется только точноодин раз.(Нет дубликатов в другом направлении.)
• и т. Д.

Возможно, вам также придется беспокоиться о датах вступления в силу цены.Т.е. как выкатить новый набор цен скоординированным способом.

Answer 2

Я бы использовал две таблицы, Location и TravelPrice.

Location
----------
LocationID --PK
Name

TravelPrice
-------------
TravelPriceID --PK
DepartureLocationID --FK to Location
DestinationLocationID --FK to Location
Price
StartDate --date the price is effective from
EndDate --date the price is effective to (or NULL)

Это позволяет вам вести историю цен, важную для отчетности, выставления счетов и т. Д. В идеале вы должны иметь триггер в таблице TravelPrice, гарантирующий отсутствие пропусков или совпадений дат для данной DepartureLocationID / * 1006. * комбинации, и что для этой пары существует только одна запись с NULL EndDate.

Answer 3

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

LeavingFrom, TravellingTo, Price

Кроме того, по мере роста списка получателей, производительность запросов и обслуживание кода будут становиться фактором.