Как организовать хранение сложных прайсов в базе данных?
Здравствуйте. Имеется проект на Laravel. Одна из задач - формировать стоимость по формуле объем_поставки_товара*цена_за_условную_единицу. Объем поставки вводит пользователь. Цена за единицу формируется из нескольких параметров. Сложность в следующем: каждый отдельный набор опций формирует отдельную (не считаемую по формуле) стоимость.
Вопрос: как организовать модель в Laravel для хранения таких прайсов?. Я думал создать модель "Критерий", содержащую все свойства товара вместе с их id. В модели "Прайс" указать (в абстрактном варианте) id и цену. Привязку вариативности сделать через связь многие ко многим. Т.е. от клиента приходит массив из выбранных критериев, а в таблице ищется прайс, к которому относятся эти и только эти критерии.
вообще, как правило, вычисляемые поля не хранят в БД, ты должен хранить и тянуть те данные с бд, который составляют эту конечную стоимость и считать её уже на бекенде
Возможно, из моего описания сложилось некорректное понимание задачи в целом. Я описал ее подробнее в комментарии к другому ответу. Сам я решил проблему через отдельную таблицу "Прайсы", где для каждого набора входных параметров (благо ветвление не очень большое) хранится значение стоимости. Часть критериев и параметров удалось упростить/формализовать/убрать, поэтому в моем случае львиная доля решения - работа над задачей, над ее пониманием и выбором подхода к решению.
Первый раз слышу о хранении прайсов в БД.
Какой смысл?
В БД хранятся данные, а если вам нужен прайс - вы вытаскиваете нужные данные из БД и формируете прайс.
А хранить прайс это дикость какая-то.
Ну сохранили вы прайс в БД, а он через секунду стал неактуальным.
Наверно я не так выразился. Под понятием "Прайс" я подразумевал цену за единицу товара. Обычно в магазине вещь можно купить по одной стоимости (телевизор за 10к рублей, например). В моем случае цена зависит не только от самого товара (от этого конкретного телевизора), но и от количества закупаемых телевизоров (например при заказе 10+ цена будет 9к за телевизор), а также от того, что покупатель захочет дополнительно получить в этом телевизоре (т.е. есть у телевизора разъем HDMI, тогда он стоит единично 11к, а при оптовой поставке 9500). Из этого примера получилась матрица цен 2х2 (по вертикали количество поставок, по горизонтали - наличие HDMI). В реальной задачи может быть матрица 2х2х2, например. Как хранить такой объект в базе данных? Сложность, опять же, в том, что нет возможности отдельно вычислять ячейки матрицы (например за HDMI доплата 500 рублей), иначе бы я применил просто суммирование по каждой позиции и не занимался бы этой дичью.
Олег Правдин, Ну тут вы просто неправильно называете вещи.
Прайс это список цен на товары.
А у вас насколько я понял надо хранить розничную цену - так бы и говорили.
Она бывает как рассчитываемой - считается по формуле, так и жестко заданной, которую вручную вводят в БД.
АртемЪ, терминология взята из ВУЗовского примера по курсу БД. Там таблица "Прайс" (адаптация английского Price?) в кейсах подразумевала "предложение" на товар, т.е. связь один ко многим (ситуация, когда на один и тот же товар может быть несколько цен - акция, специальное предложение, условия и т.п.)
Средний
Средний
