Форум PHP

Ситуация: среднестатистический интернет-магазин. Товары как и везде разбиты на категории, подкатегории, подподкатегории и т.д. (неограниченной глубины)...

Вопрос: подскажите пожалста, как организовать вывод списка всех категорий (подкатегорий) в иерархическом порядке (деревом)?

Никто не знает или это просто из папки "Cash Only"?

народу лениво жевать на пустом месте одно и то же который раз.
В поиске тем "Каталог продукции" набирается не один десяток.

Замечательно, только задача стоит не в построении каталога продукции - здесь нет ничего сложного, а в логике построения БД для неограниченной глубины подкатегорий и их вывода(!) в форме дерева (например для разворачиваемого списка типа select при добавлени нового товара и т.д.)...

Я просто указал, по каким ключевым словам искать.
Но формально Вы правы.

Логика построения БД давно накатана.
Фактически один из двух методов. Adjacency lists либо Nested sets .
Первый хорош, если дерево сравнительно часто модифицируется. Вот как этот форум, например.
Второй отлично подходит , если модификации выполняются редко, и львиная доля запросов - выборка поддерева и его разворот обходом в глубину.

Это всё здорово, обязательно изучу. Но имея не столь богатый запас знаний хочу напроситься на урок:
имея таблицу категорий (в т.ч. и подкатегорий и подподкатегорий.... ) мы очень просто можем двигаться по "дереву" (давайте использовать этот термин абстрактно) на шаг вниз и вправо, т.е. "смотреть вглубину", но если у данной ветки достигнуто "дно", то каким образом вернуться на шаг вверх и вправо, при этом незациклиться. В принципе задача возвращения на 1 или 2 шага не сложна (просто зададим "координату" через масив), только как решить задачу, если нужно вернуться на несколько шагов? не вопрос можно всё описать n-мерным массивом и по средствам него "шариться" в БД, но мы же потенциально не знаем глубину и соответственно n-мерность массива. Словно ходить по коридорам, заглядывать в двери и не зациклиться на заглядывании в одну и ту же дверь, а по окончании иметь карту здания по которому и производили поиск.

процедура обхода дерева всяко зависит от того, как это дерево представлено.
Ваше представление мне не понять. Приводите пример, может так будет яснее.

Посмотрите что пишут про обход дерева (в частности левосторонний)... как программно реализовать фразы "возвращаемся – 5, возвращаемся – 2"? если необходимо возвратиться не на 2 шага назад, а на 10?

То есть Вы предлагаете написать обход дерева по его gif-картинке? :)

Читайте дальше.

да нет же... при чём здесь картинка?
Пример:
БД, в которой администратор редактирует подкатегории товаров, например:
1. HDD
1.1. Seafgate
1.1.1. >500Gb
1.1.1.1. SAS
1.1.1.2. SATA
1.1.1.3. IDE
1.1.2. <500Gb
1.1.2.1. SAS
1.1.2.2. SATA
1.1.2.3. IDE
1.2. Maxtor
1.2.1. >500Gb
1.2.1.1. SAS
1.3. WD
1.3.1. >500Gb
1.3.1.1. SAS
1.3.1.2. SATA
1.3.1.3. IDE
1.3.2. <500Gb
1.3.2.1. SAS
1.3.2.2. SATA
1.3.2.3. IDE
1.4. Samsung
2. CPU
2.1. Intel
2.2. AMD

вот и смотрим: 1.HDD далее 1.1.Seagate -> 1.1.1. >500Gb -> 1.1.1.1SAS (достигнуто "дно"), теперь необходимо вернуться на шаг назад (1.1.1. >500Gb) и вниз (1.1.1.2. SATA) и т.д. Вопрос: как реализовать этот шаг назад и вниз? если необходимо сделать несколько шагов назад (см.п.1.2., где одна ветвь длинне соседней на несколько шагов)...

может кто-нить подскажет? плиз...

Да вам Trianon вроде бы как давал ссылки на решение вопроса. Но вот не понятно, зачем "прыгать" по дереву - в верх, в низ вправо?

не прыгать, а последовательно проходить по всему "дереву".... НА самом деле прыгать придётся по записям таблицы в БД, но как организовать эти правильные переходы от одной записи к другой? особенно когда необходимо перейти на категорию ниже и на этом уровне сделать шаг вниз...

Ну как же не прыгать, если вы опять пишите - "когда необходимо перейти на категорию ниже и на этом уровне сделать шаг вниз". Для чего? Если вам требется взять конкретную категорию, зачем "скакать" по всему дереву или части ее? Если вам надо взять отдельную ветвь ее, тоже - какие проблемы, как и получить все дерево? Ссылки вам дали - пользуйтесь, получайте все дерево, часть его... Не знаю, может доктор Trianon вас поймет, а я не понимаю - к чему эти маневры в дереве )

Давайте так. Вы приведете небольшой пример дерева в виде SQL-таблицы (Adjacency List или Nested Sets)
Я покажу Вам, как прыгать.

не надо было спать на лекциях в своё время! Задача решена, всем спасибо!

Ключевое слово в решении этого вопроса - рекурсия.

Только для AL
Для NS и MP она нахрен не нужна.

Согласен =)

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

Вы, пожалуйста, не говорите лишнего. Для того же NS сколько запросов нужно?

Вы пожалуйста сами не говорите лишнего =) Кто сказал что используется именно Nested Sets?

OK.

> Кто сказал что используется именно Nested Sets?
Никто. Ровно как никто и не сказал, что оно не используется. Было лишь сказано Вами:

> для каждого обращения полььзователя строить дерево, может быть весьма неслабая нагрузка, потому что это дело совершает много SQL запросов

Значит я имею право считать, что Вы говорили и про Nested Sets, и про Materialized Path, и про Adjacency List и т.д., т.е. Вы утверждаете, что для всех этих способов организации хранения деревьев используется "много SQL запросов".

Понимаете, это как замена умножений на сложения. Сколько бы ни было умножений, но пока их можно заменить на сложения, их "слишком много".

зы Обязательно проведу на досуге основательный хронометраж.

EDIT "Много запросов" относилось не к единичному обращению к СУБД.

> Понимаете, это как замена умножений на сложения.
> Сколько бы ни было умножений, но пока их можно заменить на сложения, их "слишком много"

o_0