каждый склад и что?
я просто думаю. Допустим, в разделе 200 товаров. Это значит, что надо эти 200 товаров получить, отсеить с нулевым количеством по складу и это будет в некешируемой области, т.е. на каждом хите. Это доп нагрузка. Или надо отдельно закешировать результаты? Т.е. полученные айдишники кешируем, потом достаём из кеша в случае чего.
Можно и так и так. Никакой там нагрузки сильной не будет - один не очень сложный запрос. Хотя нужно смотреть конечно по факту. Ну будет долго - оберните в кэш этот запрос. Но что-то я думаю что долго не будет. Тем более 200 товаров - это смешно. Если бы их было хотя бы 20000, можно бы было поразмышлять.э
Кмк можно и закешировать выборку на небольшое время, смотря как часто товары уходят в 0 остаток. Образно, если раз в день, то кеш на 15-30 минут видится вполне допустимым. А при желании можно заморочиться и сделать кеш хоть на месяц, прикрутив его сброс к созданию заказа, например, если при этом по какому-то товару остаток ушел в 0.
понял, спасибо. Хорошие идеи, про это даже не подумал. Вообще, остатки по идее приходят из 1с.
А кеш меняем при апдейте, добавлении элементов или их количества.
Вы бы сначала размером каталога поинтересовались. С большой вероятностью до кеша это все просто не доедет, упадет на запросах.
Товары с аредложениями есть?
Нет, предложений нет. Простые товары.
Ну... перед компонентом делаете кешируемый метод, который будет получать свойство (id склада) по id юзера. Передаете в глобальный фильтр catalog.section, плюс параметром в вызов (чтобы в кеш подмешать). Как-то так. Если появятся товары с предложениями - схема летит в тартарары.
т.е. айдишники товаров передаём в глобальный фильтр?
Нет. Передаете условие 'количество на таком-то складе больше нуля'. Вам же это надо?
да, но я за само условие что-то не подумал. Так даже лучше, если можно передать.
не упадет - там выборка только ID нужна
Обсуждают сегодня