SQL Server Дилемма полнотекстового поиска - PullRequest
Новая
       1

SQL Server Дилемма полнотекстового поиска

0 голосов
/ 09 июля 2011

У меня есть таблица (Каталог) с одним столбцом (Заголовок).В этом столбце хранится информация о песне (исполнитель, название, ремикс).У меня есть ситуация, когда мне нужно найти совпадения по поисковому запросу.

Я включил SQL Server FTS и создал каталог FTS, используя столбец Заголовок.Я начал тестирование, используя FREETEXTTABLE, где я передаю поисковый термин.

Я обнаружил, что это возвращает ко многим не относящимся к делу результатам, хотя результаты с самым высоким рейтингом обычно являются правильными, если заголовок существует в таблице каталога.Один из подходов, который я использовал, состоял в том, чтобы преобразовать RANK в проценты и отображать результаты только в тех случаях, когда процент больше 90. Проблема заключается в том, что запрос по-прежнему возвращает несущественные результаты, если заголовок не существует в таблице каталога.

Альтернативой является использование CONTAINSTABLE.Проблема здесь в том, что мне пришлось бы динамически генерировать запрос в коде (разбивать слова), создавая что-то вроде: 

SELECT DISTINCT ft.[rank], [Id]
FROM CONTAINSTABLE(Catalogs, Title, '"artist" AND "title" AND "remix"') AS ft
JOIN [Catalogs] ON [Catalogs].[Id] = ft.[KEY]

Дилемма состоит в том, что в поисковом запросе нет разделителей.Это означает, что я не могу логически разбить строку на исполнителя и название, а только на слова.Иногда включаются другие термины, такие как метка, которая приведет к сбою вышеуказанного запроса.

Я немного застрял.Кто-нибудь сталкивался с подобной проблемой с использованием SQL Server FTS?Есть ли подход между CONTAINSTABLE и FREETEXTTABLE?

1 Ответ

3 голосов
/ 12 июля 2011

У нас была похожая проблема, когда пользователям разрешалось вводить строку поиска для бесплатного запроса, но нам приходилось использовать CONTAINS, поскольку FREETEXT возвращал слишком много ложных срабатываний.В итоге мы написали нашу собственную процедуру анализа поисковых терминов на бизнес-уровне, которая очищает строку и заменяет все пробелы на AND.Это, конечно, должно быть достаточно умно, чтобы вместить логическую группировку (когда люди используют скобки) и несколько пробелов.Кажется, у нас это хорошо работает.

Мне немного интересно узнать о структуре данных в вашем столбце.Если исполнитель, название и ремикс действительно независимые фрагменты информации, не имеет ли смысла сохранять их как отдельные столбцы и запрашивать их по отдельности?

...