Как реализовать график изменения цены товара

Аватар пользователя buldozer_kpi buldozer_kpi 17 октября в 0:44

Здравствуйте.
Есть тип материала "Товар", всего около 2000 наименований. У товара есть поле "Цена". Периодически цена товара меняется. Как правильно реализовать график изменения цены каждого товара на странице товара?

Пока пришло на ум следующая идея. Создать тип материала "Цена товара" и связать этот тип через Энтити референс или через термин таксономии с товаром. А потом с помощью Представлений и модуля Charts выводит блок типа график на странице конкретного товара. Но такое решение видится мне каким-то топорным, нужно создавать тысячи нод с ценами, а когда товар нужно будет удалить, то придется еще искать эти цены, привязанные к этому товару, и тоже удалять. Есть ли более элегантное решение задачи?
Спасибо.

Комментарии

Аватар пользователя VasyOK VasyOK 17 октября в 3:28
3

Пусть цена будет полем. Тогда для товара можно вывести все его редакции с ценами. Ну а по ценам уже построить график.

Аватар пользователя OldWarrior OldWarrior 17 октября в 3:40

VasyOK wrote: Тогда для товара можно вывести все его редакции с ценами.

Логичнее использовать поле с multiple-значениями.

Честно говоря, я бы решал подобную задачу кодом и изменения хранил в кастомной таблице БД.

Аватар пользователя marassa marassa 17 октября в 7:05

OldWarrior wrote: Логичнее использовать поле с multiple-значениями

Для цены? И где там будет храниться дата изменения цены?

OldWarrior wrote: я бы решал подобную задачу кодом и изменения хранил в кастомной таблице БД.

Зачем, когда практически вся функциональность уже есть в ядре и контрибе? Ревизии ведутся автоматически (нет необходимости отдельно что-то куда-то записывать при изменении цены, снижается вероятность ошибки), views поддерживает ревизии (по крайней мере в восьмерке), charts поддерживает views. Я сам ничего подобного не делал пока, но навскидку есть смысл хотя бы попробовать, чем сразу начинать кодить жёсткий кастом в обход всех механизмов друпала.

Аватар пользователя OldWarrior OldWarrior 17 октября в 7:42

marassa wrote: Для цены? И где там будет храниться дата изменения цены?

Как-то не думал о дате, поскольку автор не упоминал об этом. Если нужно строить график с учётом даты - да, видимо ревизии тут уместнее. Плюсанул к решению Васька.

Аватар пользователя buldozer_kpi buldozer_kpi 17 октября в 11:30

Я правильно понимаю, для этого в настройках материала должна стоять галочка "Создать новую редакцию?"

Аватар пользователя marassa marassa 17 октября в 12:40

PS Это кстати в любом случае полезно: если оператор накосячил при редактировании товара, то не нужно мучительно вспоминать что же там было до того, а можно просто просмотреть историю редактирования, и если нужно откатиться на старую версию.

Аватар пользователя buldozer_kpi buldozer_kpi 17 октября в 13:20

Тогда еще вопрос. Товар имеет много полей (разные характеристики, фото, поля таксономии для дальнейшей фильтрации и т.д.) Получается, что при каждом редактировании товара все это добро будет клонироваться в полном объеме, а соответственно и БД расти многократно?

Аватар пользователя gun_dose gun_dose 17 октября в 17:42
1

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

Аватар пользователя marassa marassa 17 октября в 13:35
1

buldozer_kpi wrote: при каждом редактировании товара все это добро будет клонироваться в полном объеме, а соответственно и БД расти многократно?

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

Аватар пользователя Valeratal Valeratal 17 октября в 15:14
1

с точки зрения объема базы
вопрос еще как часто цены меняются... Ну и , с другой стороны 2к товаров это не 200к товаров. Не слишком большая база. Всякие кэши могут кушать вообще гигабайтами

А еще есть такой модуль
https://www.drupal.org/project/node_revision_delete