перечитал ещё раз. Суть сводится к тому, что в реляционной бд нужно хранить (обширное) дерево. Решается стандартными методами, коих немногим больше чем nested sets+ещё два. Стандартными - потому что задача весьма распространена и лучшие методы давно выработаны. Крайне сомнительно, что тут заведётся девелопер сравнимого с авторами готовых методов уровня, который предложит что-то оригинальное.

> лень сейчас объяснять

> лень

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

2. materialized paths годится. Надо только разбивать строки путей на куски, не превышающие 1к символов и отразить факты разбивки в специальном поле таблицы.

3. nested sets годится. Тут приходится итти на компромисс скорости выборки со скоростью добавления. Если речь идёт о форуме, количество добавлений узлов будет на 2-3 порядка уступать количеству чтений, так что в целом по производительности несомненно будет выйгрыш. Вопрос только в его величине по сравнению с другими методами, а это вопрос скользкий.

вот щё пара методов, на первой же странице пойска в гуголе http://www.arbinada.com/main/node/25

если бы не одно но: нужна не оригинальная идея, а тыщу раз обсосатая тривиальщина http://www.google.ru/search?&hl=ru&q=хранение+деревьев+в+базе+данных

если бы не одно но: нужна не реализация, а идея. чувствуем разницу?

впрочем уже подсказали юзать хэши, что впринципе вполне неплохое решение.

/me прозреваент безработного студент-куна, ищущего где-бы подзаработать хотя бы на ролтон.

2. То что ты просишь делают за деньги.

forum.lh/first/second/third/HelloWorld.html Такой адрес должен открывать тему "HelloWorld" в форуме с названием "third", который лежит в форуме с названием "second", который лежит в форуме с названием "first".

Вопрос: как узнать ID темы, которую нам надо отобразить, если: Тем с таким названием может быть несколько, но только в разных форумах! Например: forum.lh/first/second/third/HelloWorld.html forum.lh/first/fourth/fifth/HelloWorld.html forum.lh/first/second/HelloWorld.html forum.lh/first/HelloWorld.html В данном случае это все реальные и, при этом РАЗНЫЕ темы. Более того, могут дублироватся названия форумов, но не в одном форуме. То есть forum.lh/second/second/ forum.lh/second/first/ forum.lh/first/second/ forum.lh/first/first/second/first/ Это все вполне валидные пути РАЗНЫХ форумов. Далее. Допустим, вложенность может быть очень большой. Например, 64 форума.

Повторяю вопрос и раскрываю чуть проблемы:

* Как узнать ID темы, которую нам надо отобразить.

Ситуация: 1. У нас есть только её название, которое НЕ УНИКАЛЬНО и полный путь к ней. 2. О каждом участке пути мы только знаем его неуникальное название и полный путь к нему 3. В пути может быть до 64 делений. 4. У нас есть высоконагруженная система, в которой количество запросов должно быть сведено к минимуму. Желательно, общее количество запросов(включая не только анализ пути) - не больше 15.

Решения, о которых я знаю: 1. Решение "вЛоб" Получаем айди первой секции простым запросом к базе: ${FirstID} = SELECT `ID` FROM `Forums` WHERE `Title` = `${Title}` AND `ParentID` IS NULL Получаем айди второй секции простым запросом к базе: ${SecondID} = SELECT `ID` FROM `Forums` WHERE `Title` = `${Title}` AND `ParentID` = '${FirstID}' И так пока не дойдем до последней секции, то есть темы. Решение не подходит. Причина: до 65 запросов только на получение темы.

2. Materialized Path У нас в базе хранятся полные пути к каждому форуму. Допустим, для этого у нас есть отдельная таблица "ForumsPathes" со структурой [ForumID, FullPath]. Пример содержимого: 1 | first 2 | first/second 3 | second 4 | third 5 | first/second/third Решение нежелательно. Причины: 1. Поле "FullPath" должно быть индексным varchar длинной (64*64+63) = 4159 символов. По этому полю будет регулярный поиск. Увеличение разрешенной длины названия темы/разрешенной глубины пропорционально увеличит длину поля. Решение, в общем то, ничего такое, но... "#1071 - Specified key was too long; max key length is 1000 bytes". То есть максимально-разрешенная длина в данном случае всего 1000 символов - недостаточно.

Более того, решение не должно быть слишком тяжелым для понимания (желательно, левому человеку посмотреть на код и сразу понять, как оно должно работать) и не перегружено Join'ами (скажем, максимум - 4-8 на запрос).

Пока очень застопорился на этом. Если кто сможет помочь описанием алгоритма решения этой задачи - буду рад. :)