Хочу предложить свой вариант оптимизации выполнения рутинной операции и обсудить варианты улучшения пердложенной реализации.
Задача:Одна из категорий представляет собой товары, которые допускают продажу кусками произвольной длины, пусть это будет ткань на шторы.
Цена товара рассчитывается как длина куска на стоимость метра.
При этом хотим чтобы покупатель имел возможность заказывать несколько одинаковых кусков или даже кусков разной длины.
Упростим задачу, разрешив заказывать только куски длиной из некоторого набора длин (3, 4, 5, ..., 10 метров)
Как я это реализовал в VirtueMart:В каталоге есть категория "Тюль".
Выставлены образцы товара.
Для каждого товара указана стоимость метра ткани.
У каждого товара есть свойство "Ширина", которое устанавливает цену за данный кусок, заданной длины.
Проблема:Нужно для всех товаров установить вручную свойства, да еще постоянно просчитывать стоимость, так как у разных товаров разная цена за метр.
Решение:Немного теорииСписок товаров хранится в jos_vm_product
Свойства хранятся в jos_vm_product.attribute
Кодируются как:
<Title>,<Имя особенности>[<действие с ценой "+" или "="><цена>]
Список свойств разделяется ";"
Внутри поля разделяются "," без пробела после нее.
первое поле - имя свойства
остальные список особенностей
список особенностей состоит из имени особенности и действия с ценой ("+" или "=") указанного в квадратных скобках сразу после имени особенности, без пробела, за знаком "+" или "=" идет значение особенности
Пример (два свойства, по несколько особенностей у каждого):
Варианты размеров (высота),2.30 метра[+100],2.35 метра[=200],2.40 метра,2.45 метра,2.50 метра,2.55 метра,2.60 метра,2.65 метра,2.70 метра;Ширина,3 метра[=240],4 метра[=320],5 метров[=400]
Принадлежность товара к определенной категории указывается в таблице jos_vm_product_category_xref
Цена товара хранится в таблице product_price
Для того, чтобы не вносить все свойства к каждому товару вручную пишем скрипт MySQL.
UPDATE `jos_vm_product`
SET `ship_code_id` = (SELECT `product_price` FROM `jos_vm_product_price` WHERE `product_id` = `jos_vm_product`.`product_id`)
WHERE `product_id` IN (
SELECT `product_id`
FROM `jos_vm_product_category_xref`
WHERE `category_id` =4
)
UPDATE `jos_vm_product`
SET `attribute` = CONCAT('Ширина,3 метра[=', 3 * `ship_code_id`, '],4 метра[=', 4 * `ship_code_id`, ']')
WHERE `product_id` IN (
SELECT `product_id`
FROM `jos_vm_product_category_xref`
WHERE `category_id` =4
)
UPDATE `jos_vm_product`
SET `ship_code_id` = NULL
WHERE `product_id` IN (
SELECT `product_id`
FROM `jos_vm_product_category_xref`
WHERE `category_id` =4
)
У меня jos_vm_product.ship_code_id не востребовано, поэтому использовал его в качестве промежуточного поля для хранения цены.
Для каждого товара будет сформировано свойство для которого цена за особенность будет зависеть от ширины заказываемог куска.
Хочется услышать критику по упрощению скрипта.
Возможно ли избавиться от использования промежуточного поля?
23.04.2016, 00:18:32