снова дерево и обратное дерево!

[AlexKill]

Извените, может я чего не понимаю, но дерево я не вижу.
1.Я вижу, что разбил одну таблицу ИД, Имя, Описание, Краткое описание и т.д. на кучу таблиц
Ид, Имя
Ид, Описание
Ид, Краткое описание
...
Так? Тогда это просто избыточность и ненормализованные таблицы.
Может я ошибаюсь, но это просто не видно из твоего запроса.
2. Если все таки дерево есть и все связи 1:1 или 1:N, то можешь попробовать добавить обратную связь.
Это усложнит скрипты, зато ускорит работу.
3. Если же ты используешь дерево только со связью сын-отец, то есть каждая запись знает только своего родителя, то получаешь легко расширяемую и легко изменяемую базу деревовидной структуры, но для обработки которой потребуются рекурсивные процедуры, что очень скажется на производительности.
Тут тебе надо обдумать кол-во эл-тов в базе.
Если есть вопросы, то пиши. У меня есть готовая реализация.

 

[Yuriy_S]

хм... спасибо за внимание.
Дерево мне нужно, и даже очень.
Давайте будем разбирать на примере форума, который я уже практически дописал. Есть таблица - имя форумов (табл.1), описание и прочая инфа! Есть таблица с топиками(табл.2) + таблица с сообщениями (табл.3). Не говорите что нужно делать топики и собщения в одной таблице - я знаю, но не моя идея делать так.
Теперь к дереву:
В табл. 1 есть ид форума, в табл 2 он тоже есть и в 3.
Строим мы значит дерево по Id номеру и выводим заголовки форума, затем топиков.
Получается нечто вроде небольшого дерева.
И ещё нужно сделать "обратное" - то есть сын->отец (topic_name - > forum_name). А уже сообщения выводятся потом, в виде заголовков re:****, в общем я думаю что эта структура простая. И хотелось бы узнать, как можно сделать с минимальными затратами на производительность системы.

и вообще, для 3 таблиц, это сколько запросов получится, штук 60 наверно...?

 

[Yuriy_S]

p.s для последнего будем считать, что в таблицах по 20 записей.

 

[AlexKill]

Круто!
Ну вы и замутили! Ладно, зато очень просто в реализации )

1. Рассмотрим сначало вариант вниз (например вывод всех топиков или сообщений на экран)
Если у тебя нет вложенных сообщений, то все просто
select * from table_topik, table_message where table_message.topik_id = table_topik.id and table_message.forum_id = '$forum_id' ORDER BY .... тут по обстоятельствам.
Если же есть вложенные сообщения (ответы на ответы), то одним запросом ты уже не разберешься и придется вставлять рекурсию типа

function nav_level($lvl_numer,$level)
{
GLOBAL $DATABASE,...;

$database_query = "SELECT * FROM $table_name WHERE parent_id='$lvl_numer' ";

$database_query = mysql_abfrage($database_query);

$result = @mysql_db_query($DATABASE, "$database_query");

while ($row = @mysql_fetch_row($result))
{
$id = $row[0];
$parent_id = $row[1];
...
//echo Message

nav_level($id,$level+1);
}

}
переммная level нужна что бы знать велечину отступа справа для каждого сообщения. Что бы получилось красивое дерево на экране.

2. Случай второй - поиск вверх. Я не могу представить для чего он нужет, но все таки. Тут то же два варианта.
Если нет вложенных сообщений то один запрос, если есть, то будет та же рекурсия, но наоборот.

ЗЫ. Проблемы в рекурсионных функциях, то что они гребут под себя рессурсы(запоминают промежуточные рузультаты) и генерят очень много мелких МУСКУЛ- запросов. И то и другое, критично по производительности на стороне сервера!

 

[Yuriy_S]

ok