Так вот я говорил, что получение данного кусочка на php, имхо, будет работать бустрее чем в муське.
представь себе следующую картину:
1.html-странички сайта хранятся в мускуле при fulltext индексе. Эти данные, естественно, и
просматриваются, И ДОБАВЛЯЮТСЯ, ИЗМЕНЯЮТСЯ. Сейчас мне проще просто сделать выборку части
строки по первому встречающемуся слову искомой словоформы +/-100 символов, далее полученную
строку отпарсить на наличие тегов, кусков тегов.. и вывести пользователю результат.
2.Ты предлагаешь хранить словарь слов. Я представляю себе его так:
2.1.4 таблицы - 1-ая -> слово/id, 2-я -> предложение/id, 3-я -> номер страницы/номер слова,
4-я -> номер предложения/номер слова/номер страницы.
2.2.ПРИ ЛЮБОМ ИЗМЕНЕНИИ СТРАНИЦЫ(вставка, обновление) нужно сделать следующее:
а) удалить все предложения этой страницы, связи ключевое слово/страница из 3-ей таблицы
(при обновлении)
б)отпрасить страницу на наличие тегов,strip_tags
в)разбить страницу на массив предложений, разделитель точка, точка с запятой
г)разбить каждое предложение на слова, каждое слово проверить на наличие в БД, если
его нет, добавить в БД (id слова autoincrement)
д)сделать вставку предложение в БД
е)заполнить таблицы 3,4.
Если учесть, что обновление данных будем систематическим раз в несколько дней, причем
update происходит через закачку с локальной машины, а также через dhtml форму на сайте,
то время на обновление словаря в режиме реального времени будет НАМНОГО большим, чем просто
FULLTEXT index.
Согласен в чем: скорость выборки при таком варианте хранения словаря будет быстрее, чем
fulltext index (поставить индекс на слова(5 первых символов)), и в результатах поиска будет выдавать
полное предложение, где первый раз встречается первое слово словоформы.
Недостатки:
1.объем словаря и предложений значителен
2.написание кода - желательно на сях - время
3.время при обновлении страниц - увеличиться значительно за счет проверки каждого слова
в мускуле.
Взвесим все за и против!
