Здравствуйте у меня возникла вот такая ситуация. 
Есть допустим продукт, он может быть расположен в множестве категорий. Чтобы сильно не мудрить я решил хранить в записи товара вот так /№ категории/№ другой категории/№ третьей категории/
И вприципе выборка из категории отлично происходит при помощи in ('/id_kat/'). Но вот возникла проблема. Мне нужно посчитать количество товаров в категориях. И категории многоуровневые. Т.е. мне нужно как-то проходиться по всем детям родительской категории и посчитать товары.
Т.е. 
Родительская категория (N) 
 - Ребёнок 1(X)
 ---Ребёнок ребёнка (YX)
 - Ребёнок 2(X2)
 .....
 - Ребёнок N(XN)

И вложенность бесконечная. А Число N должно быть суммой всех ребёноков. И товары могут располагаться только в конечной категории. В скобках число.

в самой категории хранить счетчик "товаров в категории". триггером при измении категории у товара делать перерасчет. единственное нетривиальное место: как в триггере, имея старый и новый списки категорий продукта(/1/5/10/12/ и /1/5/11/12/) найти отличие. после нахождения уже не так сложно будет 

Если выборка делается просто, то и посчитать количество результатов выборки тоже просто. Нет?

видимо выборка по одной категории, а подсчет по иерархии

ksnk, 
Да-да-да именно про иерархичный подсчёт я и говорю.

если строка /1/2/3/ означает, что категория 3 входит в категорию 2 и т.д., то для требуемого подсчета нужно знать, кто у данной категории родитель (до самого корня). тогда, например, если нужно подсчитать число товаров в категории 3 и потомках условие запроса будет

а для числа товаров в категории 1


Это сообщение отредактировал(а) baldina - 27.3.2012, 10:54

baldina, 
Нет просто означает в какую категорию входит. Так бы я тоже догадался выбирать по первому из запроса.

ну раз так, то

не мудрое решение))
надо мудрить

Это значит, что товар находится в разных категориях. не связанных друг с другом?

Каким образом задается дерево категорий?

ksnk, 
да в разных категориях не завязанных никак между собой, только через 0 она корень.
Дерево через id и parent_id
Т.е. все категории именно вот так. Каждая категория имеет родительского. Те которые корни, они 0. 
Т.е. там может быть допстим так.

Электрооборудование - лобзики
Электрооборудование - инструменты - рабочий инструмент
Рабочий инструмент2 - Инструменты.

И товар может находиться только в каждой конечной.
Т.е. получается в электрооборудовании будет 2 товара типа. в лобзиках 1, в рабочем инструменте 1.
Во втором родителе один товар и в Инструментах 1 тоже.

1. иерархические запросы на sql, специфично для ЯБД. пример для mysql тут
2. если количество товаров не слишком велико, можно загрузить их в массив и обработать на php

Фиговое решение :( выполните нормализацию искать и считать станет проще.

Т.е. у вас собственно 2 задачи 
- найти все категории внутри родителя.
- посчитать число товаров по этим категориям.

Fortop, 
Предложите лушчий вариант, сказать что фиговое решение любой может.

Serious2008, я вам уже предложил.
Храните категории отдельно.
Или nested sets или почитайте это http://demiurg.livejournal.com/53125.html
http://mikehillyer.com/articles/managing-h...-data-in-mysql/

materialized path если очень уж сильно нужен зачем-то - оставьте, но помните что обновлять надо будет в нескольких местах.

Добавлено через 2 минуты и 7 секунд
Ах, да, у вас же даже не MP

тогда тупо нормализуйте БД

Заведите таблицу отношений
Товар-Категория

и делайте выборку по ней.

Итого, для категории X нужно найти все подкатегории и суммировать количество товаров в них.
Все подкатегории категории X вычисляем рекурсивно, чем-то вроде

Находя всех чилдов, у каждого чилда - своих чилдов и так далее... Сильно оптимизировать, при такой структуре данных не получится. При желании - список подкатегорий можно хранить в самом узле, пересчитывая его по мере изменения.

Получается список всех чилдов узла.

Запрос, вычисляющий количество товаров в категории - 


Надо бы смотреть в сторону nested sets, для хранения дерева категорий. Там задача вычисления чилдов решается в один простой запрос.
Сами категории товара хранить в отдельной таблице. {id товара; id категории}

Хотя сначала надо сделать систему кэширования результатов подсчета, так как эффективная схема хранения данных все равно от этого не спасет.