Использование подсчета в Opencart

[AlexDW]

созрел для первого своего вопроса на форуме :ugeek:

 

пытался понять, но так и не въехал в смысл использования двойных запросов в движке - сначала для получения элементов, а потом для их подсчета

(getProducts/getTotalProducts и тд)

 

есть какая-то особая причина для их разделения, вместо использования например глобальных переменных для получения количества через ->num_rows в одном запросе?

 

или же отдельный запрос вида SELECT COUNT будет работать быстрее подсчета итоговых результатов через ->num_rows в первом?

 

буду благодарен за пояснения

[snastik]

  Цитата

или же отдельный запрос вида SELECT COUNT будет работать быстрее подсчета итоговых результатов через ->num_rows в первом?

 

 

1. В некоторых ситуациях - да действительно такая конструкция работает быстрее.

2. В 1.5.5.1 была модификация от toporchillo, с подобной реализацией.

 

Это все хорошо, но есть одно большое НО.

 

Подобного рода модификации вносят существенную денормализацию в исходный код opencart и вызовут в массе очень большие проблемы с несовместимостью дополнений. Любой фильтр, использующий стандартные методы выборки/подсчета скажет вам "спасибо" автоматически.

[sv2109]

getProducts получает не все товары, а только те, что нужны для конкретной страницы, напр. 20 штук., там есть limit

поэтому num_rows вернет 20 штук

а getTotalProducts нужен для пагинации чтобы получить все товары.

 

можно разве что использовать SQL_CALC_FOUND_ROWS чтобы не дублировать 2 запроса. 

[chukcha]

->num_rows

считает только результат самого запроса

 

 

Да, решение из 1.5.5.1 хорошо, но до фильтров, потому как фильтры, в основном, юзают свои модели

[AlexDW]

не-не, понятно что будут проблемы если править стандартное

меня интересовало именно в плане создания своих модулей

 

про модификацию topochillo через FOUND_ROWS в курсе, одно время даже использовал - пока не столкнулся с проблемами совместимости

[AlexDW]

  В 23.09.2016 в 13:21, sv2109 сказав:

getProducts получает не все товары, а только те, что нужны для конкретной страницы, напр. 20 штук., там есть limit

поэтому num_rows вернет 20 штук

точно, порой самое очевидное и не замечаешь :ugeek:

[SyntaxCode]

Кстати между FOUND_ROWS и COUNT есть загвоздка, в зависимости от запроса они могут заброса по разному 

https://www.percona.com/blog/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

 

я вот не понимаю, почему бы не вести просто отдельную таблицу типа Totoal и писать туда количество, это же в разы скорее будет работать чем перелопатить всю таблицу 

[chukcha]

а кто туда будет писать и когда

 

Это если у вас запрос простой то это еще подойдет

 

А если нужно  отфильтровать по цене? То?

И с категорией?

И по производителю? То?

 

Опять не туда. Не ищите проблем там где их нет..

 

Хотите оптимизировать?

У вас один магазин?

У вас один язык?

У вас есть длина и вес?

У вас есть производители?

[snastik]

  В 23.09.2016 в 13:37, ArtenPitov сказав:

Кстати между FOUND_ROWS и COUNT есть загвоздка, в зависимости от запроса они могут заброса по разному 

https://www.percona.com/blog/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

 

я вот не понимаю, почему бы не вести просто отдельную таблицу типа Totoal и писать туда количество, это же в разы скорее будет работать чем перелопатить всю таблицу 

Потому что, это дополтельные избыточные транзакции.

И при прямых руках, оба запроса, как SELECT *, так и SELECT COUNT(product_id) - впихиваются в несколько мс.

[SyntaxCode]

  Цитата

 

Потому что, это дополтельные избыточные транзакции.

Не подумал об этом

 

  Цитата

 

И при прямых руках, оба запроса, как SELECT *, так и SELECT COUNT(product_id) - впихиваются в несколько мс.

Тогда Вывод сей пянки отдельный запрос с SELECT COUNT(product_id) будет скорее  чем SQL_CALC_FOUND_ROWS

[snastik]

Тогда Вывод сей пянки отдельный запрос с SELECT COUNT(product_id) будет скорее  чем SQL_CALC_FOUND_ROWS

Нет не будет.

Но SQL_CALC_FOUND_ROWS - это серьезное вмешательство в достаточно критичную структуру. А ее лучше не трогать такими радикальными методами.

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

[AlexDW]

сейчас как раз тестирую различные способы

метод с FOUND_ROWS работает на движках ниже 2200, но уже не катит в нем

[SyntaxCode]

  В 23.09.2016 в 13:54, AlexDW сказав:

сейчас как раз тестирую различные способы

метод с FOUND_ROWS работает на движках ниже 2200, но уже не катит в нем

После теста бросьте результаты, всем будет интересно )

[AlexDW]

попробовал получение количества через ->num_rows ДО limit в запросе

т.е. в итоге запрос как бы один, но выполняется дважды - сначала без лимита, потом с ним

 

есть смысл такое использовать, будет какой-то выигрыш?

или забить и юзать раздельными как в движке?

[markimax]

COUNT - медленее SQL_CALC_FOUND_ROWS

Но переделывать opencart, как сказал snastik под SQL_CALC_FOUND_ROWS нет смысла, так как нарушается целостность системы

Это если вы создаете свой запрос то лучше использовать SQL_CALC_FOUND_ROWS, но аккуратно, особенно с подзапросами

 

Если товаров не много и посетителей "в секунду" тоже мало, то разницы в скорости между COUNT и SQL_CALC_FOUND_ROWS практически НЕТу

Это если у вас нагруженный сервер посетителями и товаров "миллион" тогда, да, разница переходит критичную линию и существенна