Привет. Пишу магазин. Вопрос ) Может кто знает... Товар может принадлежать

нескольким категориям. Ну соответственно есть три таблицы: товары, категории, товары_категории (связь). Все бы хорошо, но у категорий есть иерархия. Например: Одежда > Верхняя одежда > Куртки
Если нам например товару надо присвоить категорию "Куртки". В связующей таблице создается запись id товара - id категории "куртки". Но...
Ясно что в категориях которые выше по иерархии товар отображаться не будет, если не будет соответствующей записи. Вроде можно напихать тыщу связей в эту таблицу и успокоиться, но смотрю что большинство cms известных так не делают. Вместо этого присваивается только одна связь, а те категории которые выше автоматом отображают товар тоже. Как? Ну я так понимаю рекурсивное построение дерева от категории, на которой находится пользователь. Т.е. если пользователь в категории одежда, то от одежды строится дерево, берутся все айдишки и по ним из связующей таблицы делается выборка товаров. Вроде тоже гуд, но блин это ж ресурс хавает значительно, тем более при каждой загрузке любой категории. Можно иерархию каждой категории конечно закэшить, но это тоже костыли какие то. Короче, кто посоветует, как тут лучше сделать? )) Ох я и письмо написал... 😁

я обычно что-то типа такого делаю — https://pastebin.com/GBdj0J59 там все выборки по ПК идут, т.е. очень быстро. а с nested sets только лишние ненужные проблемы потом вылазят

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

Я такое делал, но одним запросом и потом перебором массива. Смотря как у тебя форма с фильтрами строится. Т.е. получаешь все связи id-атрибута - id-товара, потом перебором массива считаешь количество товаров по каждому атрибуту. Ну и закладываешь в массив, по которому форма будет генерироваться... Но по факту в юзабилити пришли к выводу что эти цифры нахер не нужны. Гораздо проще когда есть проверка перед отправкой формы асинхронная, которая выводит количество товаров по примененному фильтру на кнопке.

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

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

причем тут "база ляжет"? посмотри что я выше написал. один запрос и дальше перебор массива.

было конечно. EAV и фасетный поиск. делал в два запроса с одним фильтром: один с аггрегацией для счётчиков по оставшимся свойствам, другой — уже для вывода каталога. ты в GET запросе передаёшь что-то типа ?property[8]=32 — свойство 8, значение 32; пробегаешься по property и на каждое вызываешь скоуп у запроса по продуктам $query->joinFilterOption(8, 32), где добавляешь CROSS JOIN LATERAL () с фильтром по свойству (он должен вернуть 0 или 1 ряд(!!) в зависимости от наличия свойства у продукта. поля не важны). с несколькими "активированными" свойствами запрос получается экранов на 5, но т.к. все выборки идут по целочисленным ПК, выходит очень быстро. миллисекунд за 20-30 отрабатывает на сотнях продуктов и десятках свойств. на 100К+ продуктов скорее всего будет тормозить. ну да там уже в основном только денормализация и кэш спасают в большинстве случаев.

А есть какие-то источники про это почитать? Ато я не могу нагуглить что-то нормальное