Поиск в MySQL, но пропуская весь HTML код, если такой встречается...

[bovkun]

Поиск в MySQL, но пропуская весь HTML код, если такой встречается...

Хочу устроить поиск по сайту, но столкнулся с проблемой. Как устроить поиск по MySQL, пропуская весь HTML код, если такой встречается в тексте ?

Например, часть текста: <div class="div1">div</div>

При поиске "%div%" нужно находить только тот вариант, который является текстом, а не кодом html.

 

[SeazoN]

strip_tags() ?

 

[bovkun]

Щас посморим. Вполне возможно... ))
Спасибо.

 

[bovkun]

Хмм.... так-то оно может и так, а как эту выборку в таком случае сделать, если
WHERE ... colunm LIKE `%div%`
??

 

[leosha]

Это к вопросу о раздельном хранении контента и оформления. Боюсь, просто, красиво и непринужденно в данном случае ничего не получится.

Не не хранят обычно в базе готовые страницы с оформлением.

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

Можешь также наворотить скрипт, который проверяет чего там нашли и отбрасывает неверные варианты.
Это, наверняка проще.

А на самом деле, не часто кто-то ищет по словосочетанию
div +hr +href +align... =)

 

[Crazy]

Re: Поиск в MySQL, но пропуская весь HTML код, если такой встречается...

Автор оригинала: bovkun
При поиске "%div%" нужно находить только тот вариант, который является текстом, а не кодом html.

Вывод: отдельно хранишь то, что показываешь, а отдельно -- то, по чему ищешь (без тэгов).

 

[idencial]

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

div +hr +href +align

а за другое:
Например есть название сайта somesite.com
Для подписи в источнике новости используется somesite, а при этом новости (оправдано) хранятся в БАЗЕ в html, т.к нужно вставлять картинки и оформление не у всех новостей стандартное, таблички там разные и все такое.
Таким образом при поиске по somesite я получаю записи, где somesite вроде и нет, но он есть в ссылках на картинки, например <img src="www.somesite.com/img/img.gif">

Т.е проблема поиска в таких базах не раздутая, а достаточно актуальная, как мне кажется.

Вывод: отдельно хранишь то, что показываешь, а отдельно -- то, по чему ищешь (без тэгов).

В свое время мне пришла идея искать, делать striptags(), класть во временную таблицу и искать по ней снова, но я понял, что при большом количестве посетителей слишком много будет временных таблиц =( В общем идея бредовая.
В тоже время я не могу держать две базы - одну с оформлением, другую без, т.к
1. Поиск идет не только по новостям
2. Только база новостей занимает 35-40 метров

Поэтому ищу (пока безуспешно) новые пути решения этой проблемы. Может кто-нибудь подскажет что-то новое и разумное?

 

[Макс]

храни 2 версии новостей - одна которую показываешь (в html) вторая по которой ищешь (без ХТМЛ, я бы еще пунктуацию, левые символы и повторяющиеся слова удалил)

 

[idencial]

В тоже время я не могу держать две базы - одну с оформлением, другую без, т.к
1. Поиск идет не только по новостям
2. Только база новостей занимает 35-40 метров

При этом там есть еще несколько разделов сайта, где данные хранятся с оформлением и занимает это все метров 50, если не больше и занимать будет все больше и больше =(
Этот вариант не совсем подходит

 

[Макс]

hint: поисковой индекс (если его сформировать так как я описал) будет занимать примерно в 3 раза меньше места (а то и еще меньше - зависит от текста) чем просто статьи в ХТМЛ и поиск по таким объемам будет вестись быстрее (по моим тестам) и правильнее (т.к. не будет левых тегов).

Можешь посмотреть какой объем получиться.

function get_index($text) {
   $text = strip_tags($text);
   $text = preg_replace("/[^A-Za-zА-Яа-я0-9_\- ]/s", " ", $text);
   $ar = preg_split ("/[\s,]+/", $text);
   $text = implode(" ", array_unique($ar)); 
   return $text;
}

 

[idencial]

Так может сделать так?
Делаем таблицу temp_search, далее
Человек вводит запрос, мы ищем, находим, обрабатываем (к примеру как ты написал) и записываем в temp_search, а далее ищем по ней.
В таблице temp_search будет как бы образовываться индекс за день, а в конце дня по cron'у чистим ее.

 

[Макс]

Человек вводит запрос, мы ищем, находим, обрабатываем (к примеру как ты написал) и записываем в temp_search,

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

ЗЫ
только что сохранил эту страницу форума (100 кБ), на выходе функция выдала 5 кб (хотя много лишнего все равно оставила, например стили, яваскрипты).

 

[idencial]

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

Почти. Чистить я собираюсь в конце каждого дня.

Я бы так не делал - тормоза будут, особенно в поиске с большим кол-вом совпадений

Да я в принципе тоже к этому склоняюсь.

Просто не хочется сейчас формирование таблицы с индексом подключать к скрипту внесения новостей.
А помимо этого поиск будет проходить в разных разделах, а значит и индекс придется делать как минимум для 3 таблиц, а позже и может быть до 5-8.
Не совесм удобно.