[download] Модуль вывода товаров для VirtueMart (1.2.3 и 2.1) - страница 9 - [VM1] Дизайн, оформление

GROUP BY был добавлен, после того как на одном из сайтов обнаружились одинаковые записи для товаров и distinct выдавал неправильный результат. Но то был единичный случай, для большинства действительно будет достаточно такой модификации.
Надо не забыть оттестировать в новой версии

Distinct в таком запросе может выдавать ошибку только в случае ошибок в базе данных. Эти ошибки устраняются проверкой индексов, перезагрузкой базы данных и т.п.. Так что можете смело возвращать Distinct обратно. У себя я это уже сделал.

GROUP BY был добавлен, после того как на одном из сайтов обнаружились одинаковые записи для товаров и distinct выдавал неправильный результат. Но то был единичный случай, для большинства действительно будет достаточно такой модификации.
Надо не забыть оттестировать в новой версии

Как вариант можно RIGHT JOIN заменить на JOIN. RIGHT здесь нужен только для подстраховки с работой на некорректной базе. Например, будут выводиться товары у которых нет цены или категории. И зачем нам выводить такие товары?...  Без RIGHT запрос должен работать быстрее.

beliyadm, скажите, а вы можете доработать модуль за разумные деньги? Например добавить возможность отображения кнопки "купить".. и с ценой... почему-то при выборе валюты остается та, что забита в товаре, а не пересчитывается. Думаю многие здесь бы остались благодарными.

Как вариант можно RIGHT JOIN заменить на JOIN. RIGHT здесь нужен только для подстраховки с работой на некорректной базе. Например, будут выводиться товары у которых нет цены или категории. И зачем нам выводить такие товары?...  Без RIGHT запрос должен работать быстрее.

именно потому RIGHT и был добавлен, ибо по основному требованию было нужно выводить товары и без цены в том числе.
Какой то еще параметр был, уж не помню сейчас что конкретно.
В общем надо подумать.
Но - RIGHT и группировка будут давать хоть какую то нагрузку на достаточно большой БД в десятки тысяч позиций.

Тормозить запрос может только GROUP BY pid. Эта фраза в запросе не нужна. Но если убрать, то возможно будут дублироваться записи. Чтобы избежать дублирования на всякий случай после SELECT добавить DISTINCT. Файл helper.php.

примерно так:

$query = 'SELECT distinct p.product_id AS pid, p.product_sku AS psku, p.product_thumb_image AS pimage, p.product_name AS pname, ' .
      'cat.category_flypage as flypage,' .
         ' cx.category_id AS catid, '.$ceil_price.', p.product_s_desc AS pintro, pp.product_currency AS currency, p.product_discount_id AS discount'.
         ' FROM #__vm_product p ' .
         ' RIGHT JOIN #__vm_product_category_xref AS cx ON p.product_id = cx.product_id'.
         ' RIGHT JOIN #__vm_product_price as pp ON pp.product_id = p.product_id ' .
         ' RIGHT JOIN #__vm_category AS cat ON cx.category_id = cat.category_id'.
         ' WHERE p.product_publish= "Y" '.$where.' ORDER BY '.$ordering.' LIMIT '.$max_items.'';

проделал данные изменения - результат не заметен.
ради интереса отключил модуль - сайт летать не стал, но скорость повысилась раза в 4-ре (вместо 5-7 сек раньше, сейчас на загрузку страницы требуется от силы секунды 1.5)

именно потому RIGHT и был добавлен, ибо по основному требованию было нужно выводить товары и без цены в том числе.
Какой то еще параметр был, уж не помню сейчас что конкретно.
В общем надо подумать.
Но - RIGHT и группировка будут давать хоть какую то нагрузку на достаточно большой БД в десятки тысяч позиций.

Здесь два выхода.

1. Поставить флажок. Кому нужно быстро пусть ставят цены. А кому нужно без цен пусть ждут.
2. Разбить этот запрос на несколько запросов. ТОгда все будут летать....
   Потому что все условия по выборке данных работают только для таблицы wm_product. Если выкинуть сортировку (там где это возможно) будет еще быстрее. Т.е. сначала делается запрос к таблице wm_product, а затем результат соединяется с остальными таблицами. Во второй фазе уже можно для всех использовать RIGHT JOIN и сортировку. На любой базе такой запрос будет работать быстро. (Не знаю поддерживает ли MySQL временные таблицы. Если поддрерживает, то проблема решается за полчаса)
3. Есть еще вариант. Плюнуть и оставить как есть

Лично я у себя уже убрал RIGHT

(Не знаю поддерживает ли MySQL временные таблицы. Если поддрерживает, то проблема решается за полчаса)

поддерживает, CREATE TEMPORARY TABLE
В общем надо попробовать и погонять в разных режимах. Единственно что для более точной статистики отладки нужна база хотя бы на несколько тысяч товаров и категорий. Раздобуду - обязательно поэксперементирую на практике

проделал данные изменения - результат не заметен.
ради интереса отключил модуль - сайт летать не стал, но скорость повысилась раза в 4-ре (вместо 5-7 сек раньше, сейчас на загрузку страницы требуется от силы секунды 1.5)

Есть еще вариант. Возможно нужно оптимизировать таблицы. В  Informix есть команда UPDATE STATISTICS.  После ее выполнения запросы работают раз в 20 быстрее. Как это сделано в MySQL не знаю, но должно быть. В phpAdmin есть кнопка оптимизировать талицу, зачит должна быть и SQL команда....

В общем надо попробовать и погонять в разных режимах. Единственно что для более точной статистики отладки нужна база хотя бы на несколько тысяч товаров и категорий. Раздобуду - обязательно поэксперементирую на практике

Попросите базу у tegr. Он в этом кровно заинтересован. Есть еще вариант. Сделать компонент с разбитыми запросами и отдать tegr для тестирования.

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

как же все-таки сделать кнопку купить? Простите за приступ тупости, но не получается никак,
прочитал всю ветку сначала, решения так никто и не сказал - тупо ткнули пальцем на горизонт, ищите там..

в общем хотелось бы как на среднем рисунке.

проделал данные изменения - результат не заметен.
ради интереса отключил модуль - сайт летать не стал, но скорость повысилась раза в 4-ре (вместо 5-7 сек раньше, сейчас на загрузку страницы требуется от силы секунды 1.5)

Оптимизация таблиц
mysqlcheck  http://phpclub.ru/mysql/doc/using-mysqlcheck.html
OPTIMIZE    http://www.mysql.ru/docs/man/OPTIMIZE_TABLE.html

Попробуйте запустить запрос в phpAdmin до оптимизации и после оптимизации. Сколько секунд это займет.
Для сравнения можно протестировать штатный компонент virtuemart

SELECT * FROM jos_vm_product p 
WHERE p.product_publish= "Y"  AND p.product_special = "Y"  GROUP BY pid  ORDER BY  p.product_id DESC  LIMIT 15;

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

PS: Прошу извинить, что в предыдущем посте в  Вашем имени из 4 букв сделал 2 ошибки

dimekh - вы можете мне в личку скинуть дамп таблиц VM c указанием версии компонента и движка на котором установлено? И плюс скриншот настроек модуля.
Попробую у себя локально повторить ситуация в процентном отношении к нагрузке

Оптимизация таблиц
mysqlcheck  http://phpclub.ru/mysql/doc/using-mysqlcheck.html
OPTIMIZE    http://www.mysql.ru/docs/man/OPTIMIZE_TABLE.html

Попробуйте запустить запрос в phpAdmin до оптимизации и после оптимизации. Сколько секунд это займет.
Для сравнения можно протестировать штатный компонент virtuemart

SELECT * FROM jos_vm_product p  
WHERE p.product_publish= "Y"  AND p.product_special = "Y"  GROUP BY pid  ORDER BY  p.product_id DESC  LIMIT 15;

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

PS: Прошу извинить, что в предыдущем посте в  Вашем имени из 4 букв сделал 2 ошибки

За ошибки в имени не обижаюсь, некоторые и в слове хлеб 4-ре ошибки делают.

итак, по порядку:
1 - изначальный запрос от модуля к БД выполнялся  3-5 сек.
2 - после оптимизации БД по вашему совету время запроса сократилось до 1-2.5 сек.
3 - запрос вида "SELECT * FROM jos_vm_product p
WHERE p.product_publish= "Y"  AND p.product_special = "Y"  ORDER BY  p.product_id DESC  LIMIT 15;"
и до и после оптимизации имел равное время выполнения -  <0.015 сек.
4 - ПОСЛЕ удаления из запроса слов RIGHT - запрос стал летать - время запроса <0.03 сек.

Вывод:
 -Большие базы надо оптимизировать
 -Объясните про слово RIGHT в запросе.

конечный вид запроса:

SELECT distinct p.product_id AS pid, p.product_sku AS psku, p.product_thumb_image AS pimage, p.product_name AS pname, cx.category_id AS catid, floor( pp.product_price ) AS pprice, p.product_s_desc AS pintro, pp.product_currency AS currency, p.product_discount_id AS discount
FROM jos_vm_product p
RIGHT JOIN jos_vm_product_category_xref AS cx ON p.product_id = cx.product_id
RIGHT JOIN jos_vm_product_price AS pp ON pp.product_id = p.product_id
WHERE p.product_publish = "Y"
AND p.product_special = "Y"
GROUP BY pid
ORDER BY p.product_id DESC
LIMIT 15 ;

Terp - еще раз спрашиваю - вы можете мне скинуть свою базу (что не буду использовать в коммерческих целях - само собой)
Если же нет - сколько у вас категорий, сколько в общей сложности товаров? Эти минимальные данные мне необходимы для анализа логики запроса (признаю, он далеко не идеален, но писался под конкретный проект, потому могут быть некоторые поблажки)

-Объясните про слово RIGHT в запросе.

SELECT distinct p.product_id AS pid, p.product_sku AS psku, p.product_thumb_image AS pimage, p.product_name AS pname, cx.category_id AS catid, floor( pp.product_price ) AS pprice, p.product_s_desc AS pintro, pp.product_currency AS currency, p.product_discount_id AS discount
FROM jos_vm_product p
RIGHT JOIN jos_vm_product_category_xref AS cx ON p.product_id = cx.product_id
RIGHT JOIN jos_vm_product_price AS pp ON pp.product_id = p.product_id
WHERE p.product_publish = "Y"
AND p.product_special = "Y"
GROUP BY pid
ORDER BY p.product_id DESC
LIMIT 15 ;

Рассмотрим простой пример

SELECT color=red]distinct[/color] p.product_id AS pid,  floor( pp.product_price ) AS pprice
FROM jos_vm_product p
RIGHT JOIN jos_vm_product_price AS pp ON pp.product_id = p.product_id
WHERE p.product_publish = "Y"
AND p.product_special = "Y"
ORDER BY p.product_id DESC
LIMIT 15 ;

Пусть в базе данных есть таблицы с таким содержимым:
таблица product     Table Price                         
    product.id           product_id    price
    1                             1            10
    2                           

Результат запроса без RIGHT
    product_id    price
          1            10

Результат запроса c RIGHT
    product_id    price
          1            10
          2

А если по-простому, то без RIGHT запрос выбирает 15 записей, а потом соединяет с ценой. Если для категории нет записи в таблице цена, то и товар не выводиться.
   
С RIGHT запрос лопатит всю базу данных, и даже если нет записей в таблице цена товар все равно выводится.

Автор компонента объяснил, что был клиент которому как раз это и нужно. Выводить товар у которого нет цены. Из-за этого клиента у всех остальных включаются тормоза. На маленькой базе это незаметно, но Ваш случай подтвердил, что проблему решать нужно. Единсвенный способ удовлетворить всех это разбить этот запрос на несколько маленьких запросов. Тут работы на полчаса - час. Если Автор захочет, то он это сделает. Лично меня устраивает и это запрос без RIGHT.

У себя я RIGHT убрал. И, кстати, если floor( pp.product_price ) заменить на Round( pp.product_price, 2 ), то копейки обрезаться не будут. Где-раньше я выложил версию компонента где это реализовано.

Разбивать запрос не смысла, но вот внести в модуль дополнительную настройку (показывать все или только с ценой) - думаю стоит. ну и в комментариях укажу степень риска
По поводу обрезания цены - я брал наполнение магазина по умолчанию (демо), потому многие аспекты мог упустить. Но для нормальной человеческой отладки мне нужна живая БД на несколько тысяч позиций, чтобы оценить степень рисков по нагрузке и прочим параметрам
Вот кто бы предоставил... Terp-а уже третий раз прошу, безуспешно, ну а раз ему не надо и не дают мне БД для тестирования - особо заморачиваться и нет желания, поймите меня правильно

Хочется выразить благодарность Автору за прекрасный компонент. Вся ясно, понятно и просто. В стандартном пришлось бы разбираться  неделю. И не факт, что все получилось бы   

Разбивать запрос не смысла, но вот внести в модуль дополнительную настройку (показывать все или только с ценой) - думаю стоит. ну и в комментариях укажу степень риска

Разбивать запрос смысл есть. Тогда у тех кто будет работать с RIGHT на больших базах включатся тормоза. А на разбитом запросе у ВСЕХ будет работать быстро. И не нужно будет выводить доп настройку, которой неизвестно кто и как будет пользоваться. Появятся лишние вопросы. А они Вам НУЖНЫ?  И большая база для этого не нужна. Terp свою проблему уже решил. И тех статистических данных которые он привел, вполне достаточно. Хотя, конечно, мог бы из благодарности и прислать...

beliyadm, мне форум пишет, что я не могу отправлять личные сообщения. странно.
joomla 1.5.14 VirtueMart 1.1.4
прикрепляю модуль целиком.

[вложение удалено Администратором]

Terp - еще раз спрашиваю - вы можете мне скинуть свою базу (что не буду использовать в коммерческих целях - само собой)
Если же нет - сколько у вас категорий, сколько в общей сложности товаров? Эти минимальные данные мне необходимы для анализа логики запроса (признаю, он далеко не идеален, но писался под конкретный проект, потому могут быть некоторые поблажки)

Базу хозяин магазина не разрешил дать 3-м лицам.

В базе порядка 100 категорий ( для магазина на сайте используется около 30-ти )
Товаров от 20 до 100 в каждой категории ( с сайта доступно около 250 товаров )

Не доступные из интернет магазина товары и категории используются для управления поставками\закупками.
Такая вот у хозяина магазина система.

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

п.п.с. И за модуль Огромаднейшее спасибо ( если нужно как то будет протестировать его на этой Б.Д. - всегда готов.)

$query = 'SELECT distinct p.product_id AS pid, p.product_sku AS psku, p.product_thumb_image AS pimage, p.product_name AS pname, ' .
      'cat.category_flypage as flypage,' .
         ' cx.category_id AS catid, '.$ceil_price.', p.product_s_desc AS pintro, pp.product_currency AS currency, p.product_discount_id AS discount'.
         ' FROM #__vm_product p ' .
         ' RIGHT JOIN #__vm_product_category_xref AS cx ON p.product_id = cx.product_id'.
         ' RIGHT JOIN #__vm_product_price as pp ON pp.product_id = p.product_id ' .
         ' RIGHT JOIN #__vm_category AS cat ON cx.category_id = cat.category_id'.
         ' WHERE p.product_publish= "Y" '.$where.' ORDER BY '.$ordering.' LIMIT '.$max_items.'';

именно потому RIGHT и был добавлен, ибо по основному требованию было нужно выводить товары и без цены в том числе.
Какой то еще параметр был, уж не помню сейчас что конкретно.
В общем надо подумать.
Но - RIGHT и группировка будут давать хоть какую то нагрузку на достаточно большой БД в десятки тысяч позиций.

Еще раз посмотрел запрос. Запрос работает так. Выбираются все записи из таблицы Price и соединяются с таблицей product. Т.е. для конкретной базы это 20000 записей. Потом эти данные сортируются и выводится 6-10 записей (сколько мы задаем в параметрах). Причем RIGHT эквивалентно просто JOIN в самом худшем варианте.  Товары у которых нет цены выводиться не будут, поскольку таблица price является ведущей.  Чтобы товары без цены  выводились, таблица продукт должна быть ведущей. RIGHT нужно заменить на LEFT. Тогда, возможно, запрос в будет работать быстро.
   В этом случае мы полагаемся на оптимизатор MySQL. Если запрос разбить, то гарантированно получим высокую скорость.

Если terp проверит это на своей базе (заменить RIGHT на LEFT), то получим результат с реальной базы.

beliyadm, извините за вопрос не по теме.
Штатный компонент для вывода категорий в виде дерева обрезает, а не переносит длинные строки.
скачал компонент VirtueMart_Tree_Factory_Module. Он строки переносит, но при загрузке страница сначала открывает все вложенные категории, а потом после загрузки страницы их закрывает. Очень некрасиво.

Там идет код JQuery, в котором я пока плохо разбираюсь. Может у Вас есть готовый компонент для вывода категорий в виде дерева, или может что-нибудь посоветуете?

Там идет код JQuery, в котором я пока плохо разбираюсь. Может у Вас есть готовый компонент для вывода категорий в виде дерева, или может что-нибудь посоветуете?

увы, по данному вопросу ничего не подскажу, ибо компонент VirtueMart вообще как бы не использую, модуль написан по случаю

За комментарии большое спасибо, основу запроса писал на быструю руку на маленькой базе, потому не заметил проблемы

Стоит модуль версии 1.2.2  но как то уж очень странно выводится, проблема с размерами
Как с этим бороться ?


[вложение удалено Администратором]

Flanker - размеры блоков регулируются на уровне шаблона модуля, у него есть свой CSS где и указывается ширина. Текущая выбрана по размерам картинок демо контента
Открываете mod_virtuemart_universal.css и правите все что требуется
Вот собственно тот кусок, что отвечает за размеры блоков с серым бордюром

не помогает, фотографии не уменьшаются ((

не помогает, фотографии не уменьшаются ((

фотография и не будет уменьшаться, она же берется из системы как есть размеров, оригинальных превьюшек (размеры задаются, если не ошибаюсь, в настройках магазина)
Я говорил про изменение размера блока, в котором находится вся информация + фото
Можно на уровне шаблона модуля в тег IMG добавить нужный WIDTH, но это совсем как бы и нехорошо

Flanker, а галочка включена: компоненты -> VirtueMart -> настройки -> сайт -> "Включить динамическое изменение размеров для мини-изображения"?

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

а как сделать чтобы фотографии брались из маленьких превьюшек ?

а как сделать чтобы фотографии брались из маленьких превьюшек ?

за выводимые изображения отвечает поле в БД product_thumb_image, физически превьюшки лежат в components/com_virtuemart/shop_image/product/

Просто у вас настройки магазина по размеру превьюшек выходят за пределы по умолчанию заложенного размера блока в модуле, читайте выше, уже писал что исправлять надо на уровне CSS размеры блоков модуля