а если страниц будет пару тысяч? Наверно, придется закрывать доступ к сайту на время индексирования. Аесли будут коментарии к статьям и т.д. придется часто делать эту процедуру. То, что в том магазине = мой вариант. Но всеравно спасибо за совет, я просто никогда не делал такой поиск, в основном ограничивалось примитивными поисками. Для данного сайта, что я делаю этот способ сгодится, но может есть еще какие нибудь варианты. хотелось бы как-то сделать не жрущий ресурсы скрипт.

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

Я то и думал производить полнотекстовый поиск по этой таблице. Но меня больше интересует оптимальный вариант занесения данных в эту таблицу. Т.к. используется не сервер, а виртуальный хостинг. как организовать индексацию этих страниц с наименьшим сопротивлением?

300 страниц по 10 товаров меньше минуты обрабатывало.

а сама страница с товаром индексировалась?
как я понимаю по времени, это был виртуальный хостинг?

Это был локальный хостинг. Про саму страницу ничего не могу сказать. Я вскользь просматривал коды. Задача стояла совершенно другая.

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

Это получается ты будешь делать запрос на время, потом, если условие выполняется, будешь делать апдейт. Как ни крути у тебя минимум 1 запрос будет при обращении к странице. Не выгоднее ли в плане производительности делать апдейт сразу при обращении?

Мне кажется, что выборка count бысрее чем update(это чисто мое предположение), поэтому я так и сделал.

А почему, собственно?

Если на сайте пять разделов, то не надо делать пять кнопок поиска. Достаточно одной кнопки, которая запускает что-либо подобное:

$search_results='';

function search()
   {
      global $search_results;

      $search_results = array();
      search_part_1(); // Функция дописывает в массив записи по результатам поиска по первому разделу...
      search_part_2(); // ... по второму...
      search_part_3(); // Строки массива результатов поиска также сделать массивами с полями Заголовок, Раздел, Ссылка, Релевантность, Фрагмент текста, ну и так далее...
      ...
      // Если надо перемешать результаты поиска (по алфавиту, релевантности), использовать sort любого вида
   } // search()

При таком подходе можно даже сделать всплывающую формочку расширенного поиска и разрешить пользователям выбирать набор разделов для поиска. Вариантов тьма на самом деле. Поэтому стартовое ограничение несколько непонятно...

?

1. Если тотальная сортировка нужна (например, по релевантности), то в любом случае как минимум один раз придётся вывести все результаты поиска в массив. Затем в случае большого количества элементов сохранить ID в таблицу результатов поиска для данного сеанса или вообще просто тупо внедрить ID-шники записей одной строкой в скрытый INPUT. Затем просто без поиска выбирать из списка ранее полученных ID-шников нужный диапазон (с 31-й по 60-ю позицию, например). Удалённые строки показывать каким-нибудь текстом типа "Данные удалены, обновить?"

2. Если общая сортировка не важна, то кто мешает передавать в функцию поиска диапазон выводимых строк и перед каждым поиском просто проверять, достиг размер массива найденных записей той же 60-й строки? Точно также можно сохранить количество найденных строк каждой поисковой функцией в любом удобном месте и в случае перехода на вторую страницу поиск номер 1 не делать (если уже известно, что он выдаёт 6 записей, которые целиком помещаются на 1-й странице, а нам надо в данный момент отобразить вторую)...

По поводу накладного поиска в 3000 страниц — не очень понял смысл фразы. Объясняю, почему:

А) самое ненакладное — вообще не производить поиск. Нет поиска — нет проблемы.

Б) Если в результатах поиска 3000 страниц (по 30 записей на страницу = 90'000 строк (а сколько вообще записей будет в базах данных в разных разделах? Просто любопытно)), то в любом случае хотя бы один раз поиск придётся произвести и хотя бы вывести на страничку сайта список выбора страниц, заканчивающийся цифрой 3000. Если не производить полный поиск, то как узнать, что результат поиска расползается на 3000 страниц? А как ненакладно провести и обработать результат поиска в 90тыс строк, лично я не знаю. Может, Вы знаете? Поделитесь мудростью?

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

Г) Ну и когда инструментарий поиска такой «гибкий», что пользователь не сможет детализировать запрос и сократить количество результатов поиска хотя бы до трёх страниц (реально ли найти нужную информацию на 3 тысячах страниц несортированного вывода результатов, для меня лично ответ на этот вопрос может быть только один), то нафиг вообще тогда такой поиск нужен? Для галочки?

P.S.: По поводу тегов: искать в любом случае надо будет отдельные слова

select список_полей from таблица where поле like '%слово_1%' and поле like '%слово_2%'

Причём если уж совсем по-правильному всё делать, то с учётом всех словоформ. А при таком подходе пофиг, есть в тексте, в котором производится поиск, теги, или нет. Сложность будут представлять только проставленные в словах удар́ения (они разрывают слово). У себя это, видимо, буду решать дополнительным скрытым где-нибудь списком слов с проставленными ударениями (либо общим, либо приклеенным к каждой статье, не решил ещё).

зачем сразу все в массив? дестки мегобайт в массив?

не понял почему 90'000. 3000 /30 = 1000

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

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

а тут разве будет релевантность?

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

!!!

.

Да без проблем! Анализируйте предварительный размер выборки поискового запроса, в случае большой выборки перенаправляйте выборку не в массив, а в промежуточную таблицу, по критерию сортировки создавайте дополнительное поле или индекс (при сортировке через релевантность придётся дополнительно поле коэффициента релевантности вводить, просчитывать и заполнять его), идентифицируйте пользователя по сессиям или кукам для доступа именно к его сохранённому поисковому запросу, ну и очистка таблицы поиска от устаревших поисковых запросов по истечении некоторого времени... Вперёд! Дерзайте! Получится просто супер! Этим можно будет гордиться! Честно!...

При трёх тысячах страниц результата с 30 записями на каждой странице общее количество записей считается умножением 3000 на 30, а не делением. Меня лично учили так...

Вы количество страниц или записей в базах данных с количеством строк в поисковом запросе не путаете, случайно?

Вы уверены, что правильно понимаете термин «релевантность»?

Сам ещё не делал, но подскажу: тут про это есть. Причём это можно прикрутить уже вторым этапом, например. А про небольшую нагрузку при поиске с учётом словоформ — шутите, да?...

Туристы из Белоруссии точно будут искать на туристическом портале слово right?! Блин, продвинутые туристы в Белоруссии! Снимаю шляпу!

Лично я бы не заморачивался, конечно. Если туристы идут на туристический портал для того, чтобы смотреть правильную HTML-вёрстку, нехай себе смотрят. Вывод в htmlentities() заключить — и пусть получают то, что спрашивают...

Ну а уж если для продвинутых туристов писать продвинутый поиск, то почему бы не написать к этому поиску семантический анализатор поискового запроса (с выкусыванием из запроса того, что, по мнению семантического анализатора, турист не должен был бы писать в поисковом запросе, например, комбинаций английских буковок, по последовательностям совпадающих с тегами и стилями)? Гугл вообще семантику для всех языков на планете написал, а тут делов-то — один белорусский! Ну два на худой конец. Действуйте! Семантику можно даже третьим этапом сделать. Вааще круто получится! Если сделать (или хотя бы начать), конечно...