Есть каталог товаров, 3 уровня

level1
---level2
-------level3
-----------товар1
-----------товар2
-----------товар3

1) на основании каталога строится текущая коллекция вроде "зима-лето-2007"
физически выглядит в виде таблицы Collection где хранятся (товар1, товар2...)

2) на основании коллекции строятся "суб-коллекции" для разных стран "зима-лето-2007-Африка"
физически выглядит в виде таблицы Selection где хранятся (товар1, товар2...)
при отображении надо проверять входит ли товар1 из данной суб-коллекции в коллекцию

товаров -15.000, категорий уровня level3 - 1.000, коллекция - 1, суб-коллекций - 100 и т.д.

товар обновляется регулярно, категории level2-level3 скажем раз в полгода

------------------------------
теперь задача

Часто возникает проблема навигации (для админского и юзеровского веб-интерфейсов) по коллекции или суб-коллекциям. По идее можно было бы показывать дерево категорий-товаров. Из-за специфики хранения для этого каждый раз надо начинать "снизу" чтобы включить в дерево только те уровни, которые содержат товар. Кроме того дерево весьма "ветвистое" и каждый раз его строить динамически, думается, не является очень умным ходом.

Вопрос - есть ли какие-то часто встречающиеся проверенные решения для данной проблемы, либо что мне предпринять - хранить дерево в базе, если да то как (xml)?

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

если не понятно описал - поясню

level1
---level2
-------level3

хранятся в разных таблицах

возможно стоит пояснить почему возник вопрос

сама по себе структура каталога не вызывает больших проблем

level1
---level2
-------level3
-----------товар1
-----------товар2
-----------товар3

но в случае коллекций-субколлекций - эти структуры по сути являются надстройками над самим каталогом. причем в коллекцию входит не сами уровни категоризации, а именно последнее звено - товар. т.е. товар2, например, может хранится в общем каталоге, но при этом не входить в коллекцию товаров этого года, поэтому хранится связка коллекция-товарID

т.е. дополнительное хранение деревьев для коллекций-субколлекций (а их будет с сотню) будет избыточным (т.к. связку коллекция-товарID, субколлекция-товарID все равно надо хранить)

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