Уважаемые пользователи, подскажите.

1. Есть каталог, его структура представлена ниже:
  |____элемент_1
  |____элемент_2
                            |____элемент_2_1
                            |____элемент_2_2
                                                          |____элемент_2_2_1...
  |____элемент_3
  
Таблица в БД предполагается следующая:
    id integer,
    parent_id integer,
    level integer,
    title varchar(100),
    description text,
    alias varchar(40)
 
2. До каждого элемента в каталоге можно добраться по адресу 
    http://xxx.xx/catalog/element_2/element_2_2/element_2_2_1/

где   catalog - постоянное имя раздела
     element_2_2 - значение поля alias для соответствующего элемента в каталоге
        
3. Требуется оформить поиск по каталогу. Искать нужно по полям "title" и "description".

4. Результат поиска нужно представить в след. виде:
 Всего результатов: ххх
 1. элемент_1 (ссылка: /catalog/element_1/)
 2. элемент_2 / элемент_2_2 / элемент_2_2_1 / ... (ссылка: /catalog/element_2/element_2_2/element_2_2_1/.../)
Т.е. для иерархии берется цепочка title`ов и alias`ов элементов-родителей для найденного элемента
 
Собственно, проблема (на мой взгляд) состоит в построении результатов поиска, а именно, в построении цепочек title`ов и alias`ов.
Первый и самые лобовой способ - это выбрать id всех записей, удовлетворяющих запросу (т.е. SELECT `id` FROM ... WHERE `title` LIKE "%query%" AND `description` LIKE "%query%")
Затем для каждого элемента с подобной структурой таблицы рекурсивно собрать цепочки title`ов и alias`ов для навигации.

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

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

P.S. В наличие MySQL 4.1 и PHP 4.2

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

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

А что, мне понравилось (http://dev.mysql.com/tech-resources/articles/hierarchical-data.html). 
Feldmarschall, спасибо.