Вывод каталога с учетом иерархии из MySQL

[eurobax]

Ищу лучшее решение по производительности/гибкости для MySQL. А задача такая:
Есть каталог товаров

1. Бытовая техника
1.1. Телевизоры
1.1.1.Плазменные
1.1.1.1. LG
1.1.1.1.1 LG 101
1.1.1.1.2 LG 202
1.1.1.1.3 LG 505
1.1.1.2. Samsung
1.1.1.2.1 Sam 1001
1.1.1.2.2 Sam 2002
1.1.1.2.3 Sam 5005
и т.д.

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

Какие задачи еще должны решаться:
- определение полного пути до элемента
- определение принадлежности элемента группе (в т.ч. и ее подгруппам)
- быстрый перенос ветки дерева в другую ветку.

1. Nested Sets я уже рассмотрел, они не подходят под последнее условие.

2. Есть еще вариант, когда я храню все отношения между группами в отдельной таблице, там все отлично, все условия решаются одним запросом к БД. НО, иерархический вывод приходится делать скриптами (тоже один запрос, а потом рекуривная сортировка)

Какие еще могут быть предложения?

[ADSoft]

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

[soleil@mmc]

Сообщение от ADSoft

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

видимо, структура типа
id, parent_id

ТС поправит если что

[eurobax]

Сообщение от ADSoft

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

Про отношения между группами я имею в виду следующее:
1. Все записи поделим уловно на группы (есть вложения) и элементы (листья)

я храню записи <id группы>|<id подгруппы> для всех связей в дополнительной таблице.
В примере, это будут записи:
<id Бытовая техника> <id Телевизоры>
<id Бытовая техника> <id Плазменные>
<id Бытовая техника> <id LG>
<id Телевизоры> <id Плазменные>
<id Телевизоры> <id LG>
<id Плазменные> <id LG>
и т.д.
Думаю, суть понятна.
Забыл отметить, что Групп у меня не так много как элементов
Насчет оптимизации - если происходит перемещение ветки дерева, то я перезаписываю только эту таблицу (только изменения). Так же, при добавлении группы/удалении я тоже вношу изменени в эту таблицу.
Все эти операции делаются одним запросом, так что меня устраивает.

Насчет обработки результата выборки скриптами - стараюсь все вынести на SQL, если это возможно, т.к. большие объемы данных при обработке скриптами, а если там еще и рекурсия, повешают хост.
Помимо этого, я еще указал выше, какие условия должны решаться. И скриптами их реализовывать - это очень непроизводительно.

[ADSoft]

смысл понятен....
а как к примеру выглядит SQL запрос получения пути до группы или элемента.... или списка всех принадлежащих групп?

[eurobax]

Чтобы определить путь до узла (хоть группа, хоть элемент), во вспомогательной таблице помимо отношения <id группы><id подгруппы> храним еще поле <уровень группы>. Это даст возможность сортировки по уровню.
И запрос будет выглядеть типа этого:

SELECT c.caption, t.subgroup_level FROM catalog5_tree AS t
LEFT JOIN catalog5 AS c ON (c.id = t.group_id)
WHERE t.subgroup_id = "11" ORDER BY t.group_level

caption - здесь хранится название узла
catalog5 - основная таблица каталога
catalog5_tree - вспомогательная таблица с отношениями групп
t.group_id - id группы,
t.subgroup_id - id подгруппы
t.group_level - уровень группы

[ADSoft]

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

[Aza-Zel]

Братан, если разобрался, дай знать что и как, 4ую неделю бьемся, не можем сделать вывод структуры трех и более ветвей, в общем полный ппц)