Определить количество страниц (при выборке с фильтрами)

sobachnik

Новичок
Определить количество страниц (при выборке с фильтрами)

Приветствую!
У меня вот возник такой вопрос - как можно определять количество страниц при выводе записей из базы данных, если задана фильтрация? Т.е., например... есть товар, есть категория, к которой товар относится, отдельно есть записи о продавцах, отдельно есть таблица с регионами. И есть "обобщающая" таблица типа
`id_товара`, `id_продавца`, `id_региона`, `цена`
Как можно определить общее количество товаров, если, например, задан регион, продавец и категория..? Т.е. можно, конечно сперва делать запрос COUNT(`id_товара`) со всеми условиями, нужными для выборки записей в соответствии с установленным фильтром. А вторым запросом извлекать уже записи с LIMIT start, perPage... Но это два запроса и, по-моему, COUNT какой-то долгий, если строк много. Можно просто извлечь из базы все записи соответствующие фильтру, а потом уже в php пропарсить те, которые соответсвуют выбранной странице и с помощью count($array) определить количество товаров (соответственно и страниц). Но это, наверно, тоже излишняя нагрузка... Что можно сделать, чтобы знать заранее количество товаров для каждого способа фильтрации?
Вот я например в таблицу с категориями могу вносить количество товаров каждой категории. Ну и так же с продавцами и регионами. А как на счёт их всевозможных пересечений?...
Если бы было два критерия (например, только категория/продавец), то там можно было бы сделать что-то типа
Код:
            | company1 | company2 | company3
category1   |        3 |        9 |       17
category2   |        0 |       15 |       11
category3   |        5 |        6 |        8
И в дальнейшем как-то редактировать эту таблицу, а вот тут получается 3-х мерная таблица должна быть...

В общем, поделитесь, у кого какие мысли..?
 

tz-lom

Продвинутый новичок
Re: Определить количество страниц (при выборке с фильтрами)

Автор оригинала: sobachnik
Т.е. можно, конечно сперва делать запрос COUNT(`id_товара`) со всеми условиями, нужными для выборки записей в соответствии с установленным фильтром. А вторым запросом извлекать уже записи с LIMIT start, perPage...
вот это как раз не так уж и долго,особенно по сравнению с этим:
Можно просто извлечь из базы все записи соответствующие фильтру, а потом уже в php пропарсить те, которые соответсвуют выбранной странице и с помощью count($array) определить количество товаров (соответственно и страниц)
а вообще можно кешировать результаты,это добавит скорости
 

c0dex

web.dev 2002-...
Команда форума
Партнер клуба
sobachnik
SQL_CALC_FOUND_ROWS

На твою таблицу сводную - забить, вот мои идеи. Проблемы у тебя из пальца высосаны.
 

zerkms

TDD infected
Команда форума
c0dex
как раз лучше наоборот сделать отдельный запрос с COUNT()
 

fixxxer

К.О.
Партнер клуба
>>Some time ago I attended the "Optimisation by Design" course

лол понятно

вообще тут нет универсального ответа :) зависит от
1) индексов
2) селективности
 

zerkms

TDD infected
Команда форума
vovanium
кто этот cafuego вообще? :) а по теме - я где-то в начале июня писал ему в этот пост, но он мой коммент не заапрувил. там я просил раскрыть детали тестирования, а то только результаты в виде "So, it's official. COUNT(*) is dead, long live SQL_CALC_FOUND_ROWS!" не подкреплённые детальным исследованием меня как-то совсем не возбуждают.
 

vovanium

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

zerkms

TDD infected
Команда форума
vovanium
но зато там percona, что как бы намекает :)

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

vovanium

Новичок
zerkms
сколь-нибудь значительно изменить план выполнения
В данном случае я говорю о практике, а не теории, ведь в теории SQL_CALC_FOUND_ROWS сделан только с одной целью чтобы работать быстрее, чем лишний запрос с COUNT, иначе как бы смысла в нем нет...
 
Сверху