Цель вопроса: тайминги срабатывания кода или чем быстрее обрабатывается код - тем лучше!

Дано:
Если честно, речь идет о обработке $_SERVER['REQUEST_URI'] и mod_rewrite'е. Допустим поступает нам строка http://domain/pages/page_group/page_group2/page1 , соответственно, $_SERVER['REQUEST_URI'] видит /pages/page_group/page_group2/page1

Есть таблица Т в базе MySQL, в ней есть несколько полей:
 - ИД (уникальный символьный ключ). В нашем случае: page1
 - Парент (его предок). В нашем случае: group2
 - Парентс (все предки). В нашем случае: pages/group1/group2
 - Нэйм (Символическое название). В нашем случае (допустим): СТРАНИЦА1


ВОПРОС:
Нужен алгоритм (без примеров кода) как хранить или как обрабатывать данные с базы по запросу $_SERVER['REQUEST_URI'] чтобы получить вот такое:

Вход: http://domain/pages/group1/group2/page1
Выход:

или вот так: Главная->Страницы->Группа1->Группа2->СТРАНИЦА1


Допускаются любые модификации структуры базы и способов хранения данных в полях.

ВСЕМ УЧАСТВУЮЩИМ:    Большое СПС!

...пожалуйста без  оффтопа и "посылания почитать букварь", алгоритм у меня есть, хочу добится быстрой обработки...

если прям текстом так и хранится  пусть в бд, то для выбора группы почему-бы не сделать `group` LIKE 'group1/subgroup2/sasa/%' ?
хотя это и не очень эффективно

Эффективность?! не знаю,

Я даже рассматривал вариант по генерированию кода непосредственно при создании элемента или изменения ключа ИД.?! Но это бред!

Nested Tree

Я тоже думаю, что лайком неэффективно.
Самое простое - это 4 рекурсивных запроса, получающих парент. Быстро и просто.

Точно такой же вопрос только что задавали в базах данных MySQL.

Не точно такой же . Там была неизвестная вложенность, тут известная. Поэтому для решения в один запрос вместо LEFT JOIN-а мы вправе воспользоваться INNER-ом и получить еще большую скорость:

Тогда полный путь (parents) оказывается, по сути, избыточным и ненужным.

А Nested Sets, имхо, в данной конкретной задаче вряд ли даст существенное упрощение. Разве что если просто выбрать всех предков конечной страницы (это как раз в Nested Sets делается в один запрос элементарно), а уже в скрипте сравнить их состав и порядок с соответствующими элементами URI, и в случае несовпадения - редиректить на Error 404... Правда, нужно помнить, что в Nested Sets не получится легко поменять порядок вывода ветвей, и для любых модификаций дерева (добавление/удаление/перемещение) придется тем или иным образом шерстить всю таблицу...

Это сообщение отредактировал(а) SelenIT - 15.12.2007, 20:22

SelenIT, Жжешь, ща попробую... замерю и напишу   

... а что значит известная или не известная вложенность?!

Мне может прийти запрос рода http://domain/t1/t2/t3/t4/t5/t6/t7/t8/t9 - не исключено... и мне нужно будет написать чтото вроде

Главная->Tab1->Tab2->Tab3->Tab4->Tab5->Tab6->Tab7->Tab8->Tab9

...вот так!

Это сообщение отредактировал(а) webaliser - 15.12.2007, 20:24

SelenIT, а оно надо?

Комрады, а у мускула есть ф-ция типа как на ПХП substr ???

есть, а что?

...почему "как", обидно даже © 

Добавлено через 5 минут и 59 секунд

В данном случае она всегда известная - сколько "каталогов" в URI, столько же "шагов" в "хлебных крошках". А может быть модель, когда такой однозначной зависимости нет, страница с любым URI теоретически может быть потомком кого угодно - вот там однозначно рулит Nested Sets .

стоп.
у него же комбинированная таблица - материализованная смежность:



следовательно, даже джойны не нужны - строку на элементы разбиваша, запрос с or формироваша.

Feldmarschall, типа где (парентс=pages/group1 энд ИД=group2) ор (парентс=pages энд ИД=group1) ор (парентс=null энд ИД=pages) ?! 

Хороший вариант...