Здравствуйте.
Есть тип материала "Товар", всего около 2000 наименований. У товара есть поле "Цена". Периодически цена товара меняется. Как правильно реализовать график изменения цены каждого товара на странице товара?
Пока пришло на ум следующая идея. Создать тип материала "Цена товара" и связать этот тип через Энтити референс или через термин таксономии с товаром. А потом с помощью Представлений и модуля Charts выводит блок типа график на странице конкретного товара. Но такое решение видится мне каким-то топорным, нужно создавать тысячи нод с ценами, а когда товар нужно будет удалить, то придется еще искать эти цены, привязанные к этому товару, и тоже удалять. Есть ли более элегантное решение задачи?
Спасибо.
Комментарии
Пусть цена будет полем. Тогда для товара можно вывести все его редакции с ценами. Ну а по ценам уже построить график.
Логичнее использовать поле с multiple-значениями.
Честно говоря, я бы решал подобную задачу кодом и изменения хранил в кастомной таблице БД.
Для цены? И где там будет храниться дата изменения цены?
Зачем, когда практически вся функциональность уже есть в ядре и контрибе? Ревизии ведутся автоматически (нет необходимости отдельно что-то куда-то записывать при изменении цены, снижается вероятность ошибки), views поддерживает ревизии (по крайней мере в восьмерке), charts поддерживает views. Я сам ничего подобного не делал пока, но навскидку есть смысл хотя бы попробовать, чем сразу начинать кодить жёсткий кастом в обход всех механизмов друпала.
Как-то не думал о дате, поскольку автор не упоминал об этом. Если нужно строить график с учётом даты - да, видимо ревизии тут уместнее. Плюсанул к решению Васька.
Я правильно понимаю, для этого в настройках материала должна стоять галочка "Создать новую редакцию?"
Да.
PS Это кстати в любом случае полезно: если оператор накосячил при редактировании товара, то не нужно мучительно вспоминать что же там было до того, а можно просто просмотреть историю редактирования, и если нужно откатиться на старую версию.
Тогда еще вопрос. Товар имеет много полей (разные характеристики, фото, поля таксономии для дальнейшей фильтрации и т.д.) Получается, что при каждом редактировании товара все это добро будет клонироваться в полном объеме, а соответственно и БД расти многократно?
Если вы используете коммерс, то характеристики у вас в товаре, а цены в вариациях. Можно сделать ревизии доя вариаций, а доя товаров не делать
Надо смотреть как именно хранятся ревизии - возможно хранятся только поля, которые изменились, я не знаю.
Да в любом случае это такая фигня по сравнению с размером, например, картинок (я уж не говорю про видео).
с точки зрения объема базы
вопрос еще как часто цены меняются... Ну и , с другой стороны 2к товаров это не 200к товаров. Не слишком большая база. Всякие кэши могут кушать вообще гигабайтами
А еще есть такой модуль
https://www.drupal.org/project/node_revision_delete
О, а за модуль спасибо, может решить задачу