Вопрос по методу get_products

[a13x]

Кто знает зачем в классе Products методе get_products() используется переменная $group_by

if(!empty($filter['category_id']))
{
            $category_id_filter = $this->db->placehold('INNER JOIN __products_categories pc ON pc.product_id = p.id AND pc.category_id in(?@)', (array)$filter['category_id']);
            $group_by = "GROUP BY p.id";
}

вместо того чтобы в конце запроса использовать ... GROUP BY p.id ORDER BY $order?

По сути в выводе всегда нужно группировать товары по ID.

Может в этом есть какой то смысл, но какой не могу понять.

Edited November 14, 2021 by a13x

[phukortsin]

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

[a13x]

2 минуты назад, phukortsin сказал:

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

спасибо, я знаю для чего нужна группировка, вопрос был в том, почему переменная $group_by формируется только для категории, а не для всего запроса?

[phukortsin]

Потому что если в фильтре НЕТ параметра category_id, то в запросе нет INNER JOIN, и повторение товаров в результатах и так не возникнет.

[a13x]

Логично. По сути если не использовать в category_id массив с $category->children, а просто указывать category_id как число, то и группировка не нужна вобще, при условии конечно если в базе данных хранятся связи товара со всеми категориями, а не с последней. Теперь всё понятно. Зря Денис сделал так, связь со всеми категорями избавила бы систему от нагрузки, когда на сайте много категорий\вложенных категорий, например в опенкарт так сделано.

[phukortsin]

2 часа назад, a13x сказал:

Логично. По сути если не использовать в category_id массив с $category->children, а просто указывать category_id как число, то и группировка не нужна вобще, при условии конечно если в базе данных хранятся связи товара со всеми категориями, а не с последней. Теперь всё понятно. Зря Денис сделал так, связь со всеми категорями избавила бы систему от нагрузки, когда на сайте много категорий\вложенных категорий, например в опенкарт так сделано.

Если "не использовать" как сделано сейчас, а "просто указывать category_id как число", возникнут недостатки весьма серьезные.

А вообще непонятно, зачем придираться к этому месту, ибо сделано оно довольно хорошо и добротно.

[a13x]

4 часа назад, phukortsin сказал:

Если "не использовать" как сделано сейчас, а "просто указывать category_id как число", возникнут недостатки весьма серьезные.

А вообще непонятно, зачем придираться к этому месту, ибо сделано оно довольно хорошо и добротно.

Это слабое место симплы, когда много категорий то возникнут проблемы, это уже было не 1 раз.

При заходе в любую родительскую категорию, выборка будет идти по всем категориям которые включены в неё, вместо того чтобы выбрать по ID категории.

[phukortsin]

Это не слабое место, именно так и задумано.

А если Вам это не нравится, Вы легко можете изменить пару строк в ProductsView.php.

Но только простенькое изменение  в запросе -  IN(33) вместо IN(33,5,15,35,83) существенной экономии не даст.

Проблемы с тормозами в Simpla приходилось решать неоднократно, но не встречал случай, чтобы именно это место было причиной.

[a13x]

 

Цитата

Это не слабое место, именно так и задумано.

Это именно слабое место т.к. вы не работали с ИМ где очень много категорий с вложениями и вот тогда при заходе в родительскаую запрос будет содержать 100-200 ID дочерних категорий.

Цитата

Но только простенькое изменение  в запросе -  IN(33) вместо IN(33,5,15,35,83) существенной экономии не даст.

Не так, а вот так "pc.category.id = 33". Избавившись от 100-200 айди запрос будет в разы быстрее выполняться.

Цитата

Проблемы с тормозами в Simpla приходилось решать неоднократно, но не встречал случай, чтобы именно это место было причиной.

А я встречал не один раз, да и на форуме об этом я писал года 2-3 назад т.к. кто-то искал решение.