Comments 57
UFO landed and left these words here
Хабралюди восприняли это как спам и не совсем по теме статьи.
Хотя регистронезависимый юникодный поиск — это задача, которую до сих пор не могут полностью решить в крупных поисковиках. Существуют языки, в которых очень сложно построить автомат, выполняющий конвертацию между регистрами букв.
UFO landed and left these words here
И стадо дружно ставит плюсы, дабы доказать что оно не стадо, дружно ставящее минус.
UFO landed and left these words here
Вообще боюсь браться за решение подобных задач.
У текущих CMS движков поиск тоже обычно реализован на достаточно низком уровне, что удручает ситуацию.
Мне кажется, у вас лишнее слово в комментарии. 'удручает ситуацию' — звучит странно, без обид.
И да, присоединюсь — с поиском в большинстве цмс, особливо бесплатных — неахти.
UFO landed and left these words here
Я бы посоветовал интересующимся качественным SQL-поиском посмотреть доклад Олега Бартунова «Полнотекстовый поиск в PostgreSQL» на РИТ2007
«полнота и точность и ранжирование»
Что-то тут не так, запятые надо
Очень хорошо всё расписано, но как-то никаких новых мыслей так и не появилось. Google|Яндекс ищёт лучше, но имеют кучу проблем — по бритве Оккама это лучше статьи. Но я как понимаю, это только введение, а дальше нас ждёт более интересные статьи :).
Очень хотелось бы, чтобы это было так!
Я уже так устал пробовать все новое и новое в проблеме поиска…
При использовании поиска средствами SQL доступно ранжирование только по простым критериям, таким как дата.
=====
Откуда просто дата? А как же match against? Или сортировка по сумме like'ов? :)
да лайками вроде бы как не выход. А что если будет очень-очень много записей в БД, а мы по ними лайками%). Это же тормоза будут и еще какие. Можно просто составить словарь из записей и оперировать релевантностью.
Лайк по словарю, в префиксном варианте очень даже ищет :)
Можно суммировать и match against в булевом режиме.
Поддерживаю, MATCH AGAINST вполне себе хорошо и быстро работает, релевантность очень даже релевантная получается в выдаче :)
>Нельзя задавать уточнения для поиска. Например, задать поиск только в одном подразделе сайта.
Ну вообще-то это только у Яндекса нельзя, у Гугла можно, так и называется — «уточнения» :)
Нужно хорошо понимать, что стоит за api яндекса и других поисковиков. Никто не будет отдавать результаты поиска просто так, потому что имеются сложности монетизации. Поэтому Яндекс либо ограничивает количество разрешенных запросов в день, либо требует установки директа на поисковой выдаче, как в qip.ru & nigma.ru
в день 1000 запросов для среднего сайта хватит на ура. qip и nigma это уже совсем другие проблемы и решения.
в тайне под семью замками так же, как рецепт приготовления Кока-Колы


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

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

Вобщем, вы все правильно изложили, но только тогда когда у нас сайты состоят только из набора статических страниц или статей.
> # Нельзя задавать уточнения для поиска. Например, задать поиск только в одном подразделе сайта.

Невнимательно читаете, если я правильно понял ваш комментарий.
Да, не очень внимательно прочитал. Но тем неменее мысль остается — в большинетве случаев поиск или нужен с дополнительными параметрами или не нужен вообще ибо как вы правильно высказались он тутже прямиком из яндекса приводит туда куда нужно.
Беда в том, что заказчик обычно воспринимает поиск, как дешевую фичу. Типа вообще почему она не идет бесплатно «до кучи»?

Все потому, что формально эта строчка есть во всех ЦМС и во всех шаблонах с тимплейт-монстра.

Некоторый относительно недорогой вариант дает использование Zend-Lucene (из фреймворка). Даже без стемминга результат вполне удовлетворяет заказчика (интерфейс для прикручивания русского стемминга есть, и видимо люди его прикручивают). Там конечно надо дописать пагинацию, например путем сохранения результатов поиска в сессии и постраничной выборки уже оттуда, т.к. готового механизма нет. Ну и обеспечить обновление индекса при работе с объектами каталога и пр.

Совершенно с Вами согласен. Заказчик зачастую не может понять сложности реализации функции поиска, как ему не обьясняй. В результате разработчику приходится либо делать говнопоиск (под стать бюджету), либо делать хороший поиск при неадекватном бюджете, либо вообще отказываться от этой затеи.
Как правило, разработчик выбирает вариант «говнопоиск».

Я же в будущем в таких случаях буду просто идти в отказ, ибо говнопоиск делать не могу, а хороший поиск при неадекватном бюджете — не хочу (один раз пробовал — себе дороже).
Обычно дешевле выполнить запрос заново, чем сохранять его в сессию. Это связано с тем, что поиск по инвертированному индексу выполняется очень быстро, а существенное время уходит на генерацию сниппетов.
всё верно — поиск по сайту, как это, может ни покажется странным — совсем нетривиальная задача — посмотрите на тот же livestreet.ru — у него встроен Sphinx, но ведь не у всех есть возможность договориться с хостером на его установку.
>«Нельзя идеально встроить результаты поиска в дизайн сайта.»
Никаких проблем, ещё 4 года назад использовал xml поиск от yandex, надо только написать свой xsl шаблон
xml.yandex.ru/

В Google тоже не дураки работают
www.google.com/sitesearch/#xml
Выше автор уже ответил на в точности такой же коммент :)
Я даже по хабру ищу через расширенную форму яндекса — «найти на сайте»
Но видеть на хабре встроенный поиск от яндекса или гугла я бы не хотел
ИМХО, нормальный поиск по сайту начинается с анализа слов, которые вводятся в строку поиска САЙТА.
Потом берется этот анализ и разработчик интерфейса получает в лоб, если люди не могут найти очевидное.

Что касается полнотекстового поиска, то, имхо, на сайте он лишний — более эффективный поиск будет по словарю.
От того, что в описаниях ноутбуков будет найдено слово директор или кг — едва ли станет легче.

Нужна возможность настраивать результаты поиска, вручную говоря, что при запросе фамилии директора показывать на первом месте страничку с БИО, а не то, что «полнотекстовый поиск» посчитает более релевантным.

Посмотрите, как на HP.com поиск реализован — с историями поиска и подсказками — вы искали принтер, ноутбук, картридж?

Есть очень серьезный поисковый продукт atomz.com/ — там очень многие функции, недоступные бесплатным гугля-формам, реализованы.

У меня нечто типа своей системы поиска с учетом морфологии и автообучением.
Методика проста.
Добавление в словарь:
1. Есть база с распарсеным словарём ханспел, по ней находится лексема («первая» словоформа ) добавляемого слова.
2. Если такого слова в ханспел-базе нет, спрашиваем у брата-яндекса все формы этого слова и добавляем в ханспел-базу (очень помогает при добавлении фамилий).
3. В итоге добавляем лексему (или просто слова если не нашли лексему) в поисковый индекс.

Поиск абсолютно также, у искомого слова ищем лексему, потом ищем её в индексе. Всё.

Есть еще одна ступень, но её сейчас редко применяю — исправление ошибок.
Пример — spravka.properm.ru/?search=%F6%FB%F0%EA
Вот здесь тот же поисковик, но без исправления ошибок — www.business-class.su/search.php?s=%EF%F0%EE%E2%E5%F0%EA%E0
Интересное решение! Могли бы Вы привести краткий пример, как это делается пошагово? Спасибо!
Я когда то написал свой поиск, долго им гордился :-), все через поискового робота который перерывал весь сайт заходя снаружи по всем ссылкам что находил и складывал все в базу с меткой где нашел.

Сейчас я понял что это глупости и для моих проектов хорошо использовать гугл, как это свободно делают многие хорошие сайты.
UFO landed and left these words here
Кстати в догонку к комментарию по использованию Zend Lucene.

Там есть возможность, которая не упомянута в документации — давать полям документа разный вес. Т.е. например если Вам надо, чтобы по слову Контакты находилась страница «Контакты», то надо добавить вес поле с заглавием страницы.

$titleField = Zend_Search_Lucene_Field::Unstored('title', strtolower($my_symfony_object->getTitle()));

$titleField->boost = 1.5;

$doc->addField($titleField);

вот отсюда:
www.nabble.com/Zend_Search_Lucene-field-boost--td9439937.html#a9441132
Как инсайдер, обязан отметить quintura.ru. Ни в тексте, ни в коментах ее нет. Однако и с полнотой, и с точностью, и с ранжированием у нас все очень неплохо. И подогнать под дизайн сайта вполне умеем. И настроить выдачу на вашем сайте — настроим. И нужные страницы подложим. И весь инструментарий предоставим. Красота! + закладки «табы» для поиска в разных разделах одного сайта, или по разным сайтам одного издателя.
а под MSsql 2008, есть стороние решения?
мы пользовались до сих пор SQL turbo (Imceda) пока их не купил майкрософт, но так и не применил технологию.

есть решения?
многие поисковики работают с реляционными БД. Чаще всего как минимум доступен интерфейс ODBC. Достоверно могу сказать про встроенную поддержку в Sphinx&Яндекс.Сервере
Only those users with full accounts are able to leave comments. Log in, please.