Доброго времени суток!
Наверное не совсем корректное название темы, но суть вот в чем:
Имеется таблица "Расходы" в ней поле "Статья расхода".
Это поле должно содержать древовидную структуру,
Например:

-Продукты
     -Мясо
     -Фрукты
-Одежда
      -Зимняя
          -Классика
          -Спортивная
      -Летняя
         и т.д.

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

       

Это сообщение отредактировал(а) Ronin08 - 21.2.2009, 23:26

Навскидку, структура таблицы для дерева:

есть также таблица категорий и пользователей.

Судя по информации автора топика товарная номенклатура  достаточно разнородная т.е. аналитика ОДНИХ И ТЕХ ЖЕ уровней для РАЗНЫХ категорий товаров имеют разную характеристику. 
Например 2 уровень вложенности ПРОДУКТЫ раскрывает аналитику по видам продукции, а  абсолютно тот же 2 уровень для одежды уже представляет сезонную детализацию
Что бы решить проблему, стоит  определиться с максимально возможным количеством вложенных аналитик (то есть ветвей "Статья расхода").
Допустим, максимальное количество вложенности - 10 уровней.
Учитывая разрозненность смысловой нагрузки одних и тех же уровней аналитик для разных SKU, предлагаю ввести некую унификацию, т.е.  назвать данные аналитики как "субконто1","субконто2"...субконто10.(по аналогии с 1С) 
ФРАГМЕНТ таблицы

SKU           |  субконто1 | субконто2| субконто3              | субконто n|
-----------------------------------------------------------------------------------------------------------------------------------------------------------
тушёнка   |Продукты    | Консервы  | .......................................................
Шапка      |Одежда       | Зимняя      |Классика                 |
------------------------------------------------------------------------------------------------------------------------------------------------------------
Чтобы систематизировать кажущийся хаос в содержательной части одних и тех же уровней разных SKU, я например в подобной ситуации вводил некий "справочник субконто", т.е. таблицу , где для каждого товарного SKU прописана характеристика аттрибутивных группировок субконто, которые присущи данным SKU.
То есть:
Субконто1 | Тип субконто1                                       |Тип субконто2                                    |Тип субконто3              |....Тип субконто n|
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Продукты   |Детализация по товарным категориям| Детализация по группам продуктов| .......................................................
Одежда     |Детализация по товарным категориям| Детализация по сезонам                  |Детализация по стилю |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
естественно эти таблицы должны быть связаны.
В результате получишь для всех своих SKU динамически изменяемый набор характеристик + структуру базы, непротиворечущую нормализации


Это сообщение отредактировал(а) FINANSIST - 23.2.2009, 19:14

Спасибо, помог, держи "+"  

Ronin08, а почему не использовать нормальное дерево?
IDTree, IDParent, Name, ... - справочник для твоей структуры.
IDUser, IDTree, ... - кто что купил
Цепочку по IDTree вверх к родителю собрать не проблема.
В этом варианте нет ограничения по вложенности и более компактная структура хранения, но несколько усложнятся SQL-запросы.