My<cod/>.net
Используйте предложение LIKE в части внутреннего соединения
Могу ли я / должен ли я использовать критерий LIKE как часть внутреннего соединения при построении сохраненного procedure/query? я не уверен, что задаю правильный вопрос, поэтому позвольте мне объяснить.
Я создаю процедуру, которая будет принимать список ключевых слов для поиска в столбце, содержащем текст. Если бы я сидел за пультом, то выполнил бы его именно так:
SELECT Id, Name, Description
FROM dbo.Card
WHERE Description LIKE '%warrior%'
OR
Description LIKE '%fiend%'
OR
Description LIKE '%damage%'
Но трюк, который я немного подхватил, чтобы сделать разбор списка "strongly typed" в хранимой процедуре, заключается в том, чтобы разобрать список в табличную переменную/временную таблицу, преобразовать его в нужный тип и затем выполнить внутреннее соединение с этой таблицей в моем конечном результирующем наборе. Это отлично работает при отправке, скажем, списка целых чисел IDs в процедуру. Я заканчиваю тем, что у меня есть последний запрос, который выглядит следующим образом:
SELECT Id, Name, Description
FROM dbo.Card
INNER JOIN @tblExclusiveCard ON dbo.Card.Id = @tblExclusiveCard.CardId
Я хочу использовать этот трюк со списком строк. Но поскольку я ищу конкретное ключевое слово, я собираюсь использовать предложение LIKE. Поэтому в идеале я думаю, что мой последний запрос будет выглядеть следующим образом:
SELECT Id, Name, Description
FROM dbo.Card
INNER JOIN @tblKeyword ON dbo.Card.Description LIKE '%' + @tblKeyword.Value + '%'
Это possible/recommended?
Есть ли лучший способ сделать что-то подобное?
Причина, по которой я ставлю подстановочные знаки на обоих концах предложения, заключается в том, что в текстах карт используются термины "archfiend", "beast-warrior", "direct-damage" и "battle-damage".
У меня складывается впечатление, что в зависимости от производительности я могу либо использовать указанный запрос, либо использовать полнотекстовый поиск по ключевым словам для выполнения той же задачи?
Кроме того, что сервер делает текстовый индекс для полей, которые я хочу найти в тексте, есть ли что-то еще, что мне нужно сделать?
Ваш первый запрос будет работать, но потребует полного сканирования таблицы, потому что любой индекс в этом столбце будет проигнорирован. Вам также придется сделать некоторые динамические SQL для генерации всех ваших LIKE предложений.
Попробуйте выполнить полнотекстовый поиск, если вы используете сервер SQL, или проверьте одну из реализаций Lucene . Джоэл рассказывал о своем недавнем успехе с ним.
Лично я уже делал это раньше, и это хорошо сработало для меня. Единственные проблемы, которые я мог бы увидеть, это, возможно, проблемы с неиндексированной колонкой, но я думаю, что у вас будет такая же проблема с предложением where.
Мой вам совет - просто посмотрите на планы исполнения между этими двумя. Я уверен, что он будет отличаться, какой из них лучше в зависимости от ситуации, как и все хорошие задачи программирования.
@Dillie-O
Насколько велик этот стол?
Что такое тип данных поля описания?
Если любой из них мал, то полнотекстовый поиск будет излишним.
@Dillie-O
Может быть, не тот ответ, который вы ищете, но я бы выступил за изменение схемы...
предлагаемая схема:
create table name(
nameID identity / int
,name varchar(50))
create table description(
descID identity / int
,desc varchar(50)) --something reasonable and to make the most of it alwase lower case your values
create table nameDescJunc(
nameID int
,descID int)
Это позволит вам использовать индекс без необходимости реализации болта на решение, и сохраняет ваши данные атомарными.
связанный: рекомендуемый дизайн базы данных SQL для тегов или меток
трюк, который я подхватил совсем недавно.
чтобы сделать разбор списка "strongly typed" в
хранимая процедура предназначена для анализа
список в табличную переменную / временную
стол
трюк, который я подхватил совсем недавно. чтобы сделать разбор списка "strongly typed" в хранимая процедура предназначена для анализа список в табличную переменную / временную стол
Я думаю, что вы, возможно, намекаете здесь на то, чтобы поместить ключевые слова для включения в таблицу, а затем использовать реляционное разделение для поиска совпадений (можно также использовать другую таблицу для слов для исключения). Пример работы в SQL см. В разделе Поиск по ключевым словам от Joe Celko .
Производительность будет зависеть от фактического сервера, который вы используете, а также от схемы данных и объема данных. С текущими версиями MS SQL Server этот запрос должен работать просто отлично (MS SQL Server 7.0 имел проблемы с этим синтаксисом, но он был решен в SP2 ).
Вы прогнали этот код через профилировщик? Если производительность достаточно быстра и данные имеют соответствующие индексы на месте, вы должны быть полностью настроены.