Рекурсия, временное хранение информации

[Мутник]

Рекурсия, временное хранение информации

Задача такая: есть древо (структура сайта), которая состоит из 500 эелементов примерно (вложенность до 5го колена).

все хранится в базе данных в виде:

id | p_id | path | level |

При обработке скрипт просто вытаскивает все данные из БД и рекурсией выстраивает в том порядке, в котором мне это нужно. Так вот, до объемов в 50 записей все работает не дольше чем 0.01 секунды. Сейчас же столкнулся с такой проблемой, что при 500 записях - это уже 0.4-0.5 секунды.

Вопрос такой: каким образом можно вытащив данные один раз (при заходе человека на сайт) сохранить куда то эти данные, чтобы при следующем запросе их не обрабатывать снова? Сходу приходит две идеи: сериализаия и запись в файл + БД в которой это все харнить (например 10 минут, потом обновление).

есть какие то идеи?

 

[Frol]

идея: использовать другой способ хранения дерева.

 

[itprog]

Frol

вопрос: какой?

 

[Demiurg]

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

 

[Мутник]

Frol
Например? чем такое плохо?
Nested sets не хочу использовать. Какие могут быть еще идеи?

P.S. не уж то рекурсия, в принципе, так медленно работает?

-~{}~ 03.04.05 01:31:

Demiurg

Кеш - это просто инфа в файле?
В PHP же кеша как такового нет, его либо руками надо писать, либо...?

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

 

[itprog]

Мутник

Давай ты не будешь указывать, ок?

Простите, вы о чем?

 

[Мутник]

itprog

Извини, неправильно твой ответ первый понял - невнимательно прочел.

 

[Demiurg]

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

 

[Frol]

Мутник
хочется без рекурсии -- Nested Sets.
и разреши поинтерисоваться, почему не хочешь использовать?

 

[Мутник]

Frol
Да нет, дело не в рекурсии. Сейчас все стабильно работает, никаких вообще проблем нет. Просто меня сам факт небольшого тормаза смутил.

Да и тормоз то этот сам по себе ничтожен, т.к. на сайте ни при каких раскладах не будет больше 2000 посетителей в день, т.е. никто ничего не заметит.

Это чисто для себя хочется

по той просто причине, что не надо тех наворотов, которые там есть. У того же PEAR'a по-моему, даже реализация есть.

Да уж, если ничего не придумается, будем на нестед переходить.

 

[Frol]

каких еще наворотов?
PEAR причем тут?

 

[Мутник]

Frol

я про http://pear.php.net/package/DB_NestedSet

 

[Screjet]

Если не секрет, зачем вытягивать все дерево?

 

[Мутник]

Screjet

Древо - каталог товаров. Заказчик хочет, чтобы это все работало без перезагрузки, на JS (по каталогу можно было лазить). Древо само сделал, все отлично.

Как вариант - использование функции HTTPRequest, или как там ее в JS. но этого хотелось бы избежать.

 

[Screjet]

Мутник
Понимаю, сложно. Но это самый лучший вариант. + (точнее минус) большой трафик изза этого дерева.

 

[Мутник]

Screjet

Ок, как вариант. Еще один плюсик в эту сторону.

Просто там тоже есть куча НО: какие ветви открыты, какие закрыты и т.д., но это уже вопрос техники.

 

[Screjet]

Какие открыты: список открытых путей передавай через JS + cookie

Или если магазин построен на DHTML то может использовать фреймы?
А для поисковиков добавь обычный каталог.

 

[Ник]

Древо - каталог товаров. Заказчик хочет, чтобы это все работало без перезагрузки, на JS (по каталогу можно было лазить)

Недавно делал что-то подобное и выбрал следующий вариант: дерево находится в iframe, информация об открытых ветвях хранится в cookie. Сценарий пхп рисует дерево в развернутом виде и выводит массив элементов, имеющих "детей", в формате JS. Далее JS обходит этот массив и закрывает все ветви. Если у элемента есть "дети", то они помещаются в div, который потом нажатием на плюс/минус можно скрыть/показать. Все нормально работает, если не учитывать большой размер документа, получаемый клиентом.

все хранится в базе данных в виде: id | p_id | path | level |

А если раздел будет перемещен? path и level по-новому будешь считать?

 

[Мутник]

да. уже считаю.. что в этом такого?

 

[Ник]

Ничего такого в этом нет. Просто, я так думаю, не стоит хранить избыточную информацию в БД, ее проще высчитывать в сценарии.