Реализация поиска для своей КМС

[krollik]

Реализация поиска для своей КМС

Уже не первую неделю спорю с другом, он разрабатывает свою CMS (скорее даже что-то вроде фреймворка и написаной под него CMS) - недавно у него стал вопрос о реализации поиска. Ниже реализация поиска, который он хочет внедрить (а я собственно хочу его от этого отговорить):
Значит есть CMS, все модули для него он пишет сам, как собственно и всю CMS вообще. Нужно реализовать поиск по страницам: он предлагает сделать отдельного паука, который будет лазить по сайту сам (по всем его страницам, с ссылки на ссылку) и собирать весь текст - далее складировать это дело в БД, а поиск на сайте будет уже работать с данными, собраными этим пауком..
Вообщем как-то так.. Ваш вердик: имеет ли право на жизнь данная реазиция поиска в CMS. Стали бы вы так делать в CMS, если бы вы писали её с 0.

 

[флоппик]

Нужно реализовать поиск по страницам: он предлагает сделать отдельного паука, который будет лазить по сайту сам (по всем его страницам, с ссылки на ссылку) и собирать весь текст - далее складировать это дело в БД, а поиск на сайте будет уже работать с данными, собраными этим пауком..

Поздравь своего друга, он придумал Google Custom Search

 

[antson]

krollik
Пусть твой поищет в сети PHPDig.

ну а минусы этого велосипеда перечислять думую нет смысла

 

[Alexandre]

Поздравь своего друга, он придумал Google Custom Search

хорошо с этим справляется сфинкс

 

[HraKK]

Я бы тоже юзал бы сфинкс - но не у всех выделенный сервер.

 

[krollik]

Мм.. Так получается что такая реализация поиск в своей CMS оправдана? Просто раньше думал, что правильнее реализовывать сразу, т.е. чтобы либо поиск искал по таблицам, которые юзаются модулями CMS либо чтобы эти модули правильно заполняли какую-нить отдельную таблицу..

 

[флоппик]

Так получается что такая реализация поиск в своей CMS оправдана

В приведенном случае написания с нуля — вряд ли.

 

[antson]

krollik
придется все таки указать минусы/плюсы обоих вариантов.

внешний :
а)хромает оперативность
б)при переиндексации происходят лишние перезапросы всех страниц
плюс : легче в реализации, готовый скрипт можно прикрутить
к любому сайту не задумываясь о его реализации

свой.
плюсы :
ищет оперативно, зря не дергает страницы сайта
минусы:
при добавлении к проекту нового модуля с еще какойто таблицой в субд приходиться модицицировать.
сложнее в реализации (так как приходиться для каждого
найденного результата собирать урл и т.д.)

 

[krollik]

Автор оригинала: antson
krollik
придется все таки указать минусы/плюсы обоих вариантов.

внешний :
а)хромает оперативность
б)при переиндексации происходят лишние перезапросы всех страниц
плюс : легче в реализации, готовый скрипт можно прикрутить
к любому сайту не задумываясь о его реализации

свой.
плюсы :
ищет оперативно, зря не дергает страницы сайта
минусы:
при добавлении к проекту нового модуля с еще какойто таблицой в субд приходиться модицицировать.
сложнее в реализации (так как приходиться для каждого
найденного результата собирать урл и т.д.)

Не соглашусь насчёт необходимости модернизировать модуля поиска при добавлении нового модуля. Если грамотно подойти к вопросу, то можно просто определить некоторые стандарты, которые стоит соблюдать при создании нового модуля. По мне так это правильный путь при разработки КМС с нуля..

 

[Dmarck]

мм, тот самый друг, это я. Так была маленькая путаница, написал свою тему.
http://phpclub.ru/talk/showthread.php?s=&threadid=111387

Я сторонник внешнего поиска, юзать сфинкс и другие внешние сервисы нет смысла, так как сайт может быть в интранете. И гугл, с яндексом туда ну никак не проберётся. А чтобы заюзать сфинкс, нужен доступ к серверу. опять же проблема.


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

 

[krollik]

Автор оригинала: Dmarck Плюсы собственного внешнего поиска.
Про оперативность внешнего поиска, опять же запускается он по крону и индексирует ночью. Нагрузки минимальные. Что касается частоты контента, то понятно дело что если в систему модули, которые очень часто будут генерировать новый контент, то для таких модулей будут свои поиски.

Категорически не согласен. Причины:
1. Поиск может быть не актуальным (это по поводу индексации раз в день)
2. Смешивать обо способа считаю не разумным вообще.

 

[HraKK]

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

Что-то типа такого?

$responces = $this->search->addObject( 'xx_product' )->identifical( 'id' )->map( 'code' )->map( 'alias' )->
type( Core_Search::LIKE_LEFT_RIGHT )->addObject( 'xx_product_description' )->identifical( 'idProduct' )->
clause( 'idLanguage', Core_Search::EQ, $idLanguage )->map( 'name' )->type( Core_Search::LIKE_LEFT_RIGHT  );

$this->search->addObject( 'xx_product_description' )->identifical( 'idProduct' )->
clause( 'idLanguage', Core_Search::EQ, $idLanguage)->map( 'short_desc' )->map( 'full_desc' )->
type( Core_Search::FULLTEXT );

$this->search->addObject( 'xx_product_tags' )->identifical( 'idProduct' )->
clause( 'idTag', Core_Search::IN, $this->search->create( 'xx_tags' )->identifical( 'id' )->map( 'value' )->
clause( 'idLanguage', Core_Search::EQ, $idLanguage )->type( Core_Search::LIKE_LEFT_RIGHT )->fetch( $search ) )->fetch( $search );

 

[Santiago]

Не стоит путать поисковый механизм, который индексирует и ищет, и паука, который ходит по страницам.
Так вот Сфинкс - это механизм. А как и что им будет индексироваться - это уже на ваше усмотрение.