Релевантность в fulltext

[Redjik]

Что-то ничего не могу найти на тему релевантности для отдельных столбцов, толкьо IN BOOLEAN и >,<

 

[Sergey_Al]

Вот посмотри http://stackoverflow.com/questions/...t-search-relevance-to-make-one-field-more-val

 

[Redjik]

Ну лучший ответ - откровенное говнецо, а вот второй да - супер =)

 

[Sergey_Al]

Из-за лишних индексов? Про второй вариант ты серьёзно?) Мне кажется он будет тормозить и так тормознутый фуллтекст, хотя "лучший вариант" скорее всего ровно настолько же медленный будет.

 

[Redjik]

"лучший" вообще без индексов будет =)
а второй, у котрого 11 - вполне быстро отработает,
сейчас вовсю sphinx ковыряю, может там искаропки есть такой функционал, еще не нашел пока, но даже если подобным образом в нем запрос построить - он отработает in no time.

 

[Sergey_Al]

Не так тебя понял, я считал лучшим как раз тот, у которого 11, не заметил там эту зелёную птичку =)

Индексы в "лучшем" будут, ты же будешь всё равно делать для начала обычный MATCH, а потом уже релевантность считать.

select 
...
, case when keyword like '%' + @input + '%' then 1 else 0 end as keywordmatch
, case when content like '%' + @input + '%' then 1 else 0 end as contentmatch
-- or whatever check you use for the matching
from 
   ... 
  WHERE MATCH (keyword,content) AGAINST ('watermelon')
   ... 
order by keywordmatch desc, contentmatch desc

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


PS: со Sphinx тоже разбираюсь, сейчас у меня фуллтекст поиск часто работает по несколько секунд на таблице из 500.000, а мне нужна десятая доля секунды!)

 

[Redjik]

у меня сработала белая пелена =) я как только увидел wildcard search_word wildcard, сразу дальше читать не стал

and here the rest of your usual matching query

даже внимания не обратил =)
да, вариант рабочий, но я буду пробовать все же второй =)