Pull to refresh

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 вполне себе хорошо и быстро работает, релевантность очень даже релевантная получается в выдаче :)
>Нельзя задавать уточнения для поиска. Например, задать поиск только в одном подразделе сайта.
Ну вообще-то это только у Яндекса нельзя, у Гугла можно, так и называется — «уточнения» :)
«Нельзя идеально встроить результаты поиска в дизайн сайта.»
xml.yandex.ru/
только для работы нужен отдельный айпи.
Например, «студент inurl:/News/?id=»
Нужно хорошо понимать, что стоит за 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.