У меня есть хранимая процедура, которая находит конкретный адрес.
Поля
Рекорды
Мой параметр принимает только 1 полную строку
Образец:
Declare @param as nvarchar (50)
SET @param = 'Man NC'
--query where condition like @param
Результат должен быть Манила, NCR 111. Я уже пробовал этот запрос. Но явно неверно, т.к. параметр содержит город и провинцию.
SELECT c.CityName, p.ProvinceName, c.Zipcode
FROM City c (NOLOCK)
JOIN Province p (NOLOCK) ON c.ProvinceCode = p.ProvinceCode
WHERE c.CityName like '%' + @param + '%'
OR p.ProvinceName like '%' + @param + '%'
OR (c.CityName + ' ' + p.ProvinceName) like '%' + @param + '%'
Я видел сообщение здесь, в stackoverflow, предлагающее использовать ПОЛНОТЕКСТОВЫЙ ПОИСК. Но как это сделать без использования указанной функции?
@TimBiegeleisen, не могли бы вы указать мне образец пользовательской функции UDF.
Просто поищите SO некоторое время, и вы должны что-то найти.
Почему результат должен быть таким, как вы говорите? Какова логика разбиения параметра на разные столбцы? Вы правильно сохраняете адрес, почему вы не используете то же самое для параметров?
@ZoharPeled Я не вставляю записи. Записи фиксированы, а в пользовательском интерфейсе есть 1 панель поиска. Некоторые пользователи хотят просто ввести ключевые слова для города, провинции или почтового индекса, и результатом должны быть ближайшие записи, содержащие эти ключевые слова.
Я не совсем уверен, что это то, что вы хотите.
Declare @city table (city varchar(50))
insert into @city values ('Manila'),('Makati'),('Cebu City'),('Kawit')
Declare @province table (Province varchar(50),zip int)
insert into @province values ('NCR',1111),('NCR',2222),('CEBU',3333),('CAVITE','4444')
select top 1 city + ', ' + Province + cast(zip as varchar) as name from @city c cross join @province d where city like 'Man%' and Province like 'NC%'
Вы можете объединять свои поля до того, как они вам понравятся. Вам также разрешено редактировать понравившуюся строку:
SELECT c.CityName, p.ProvinceName, c.Zipcode
FROM City c (NOLOCK)
JOIN Province p (NOLOCK) ON c.ProvinceCode = p.ProvinceCode
WHERE CONCAT(c.CityName, ",", p.ProvinceName) like CONCAT('%', REPLACE(@param, ' ', '%'), '%')
Здесь я СОЕДИНЯЮ город и провинцию вместе и превращаю ваш "Man NC" в "%Man%NC%", который находит объединенное значение.
Если вы будете вводить такие запросы, как «NC Man», вы можете просто использовать OR с CONCAT, который объединяет провинцию, а затем город. Вы могли бы принять гораздо больше участия, разделив значение и т. д.; это действительно зависит от того, что вы укажете (и вы не указали много спецификаций в своем вопросе)
Если вы собираетесь делать много запросов, было бы лучше зафиксировать варианты @param и установить некоторые правила, чтобы вещи можно было лучше индексировать. Примером правила может быть: @param должен состоять из одного или двух слов, и эти слова должны представлять собой начало названия города или названия провинции или названия города и названия провинции.
С помощью таких правил вы можете разделить пространство, СЦЕПИТЬ % только в конце слов и выполнить поиск в столбцах соответствующим образом - возможно, с объединением, а не с или (может быть быстрее)
Обновлено: версия без функции CONCAT
WHERE (c.CityName + "," + p.ProvinceName) like ('%' + REPLACE(@param, ' ', '%') + '%')
Сообщение 195, уровень 15, состояние 10, строка 7 «CONCAT» не является распознаваемым именем встроенной функции. У меня есть этот результат при попытке вашего запроса. Я использую SQL Server 2008 R2.
Ого, 11 лет! Я думаю, что ваш сервер sql остро нуждается в обновлении :) Хорошо, в CONCAT нет ничего особенного, что вы не можете сделать с +, просто измените CONCAT(a,b,c)
на a+b+c
/ я просто предпочитаю concat, потому что если какое-либо значение равно нулю, оно обрабатывается как '', а не делает всю строку конкатенации нулевой
Самое главное в моем посте - заменить пробел в Man NC на %, чтобы LIKE все еще работал.
РЖУ НЕ МОГУ! Да, наши серверы немного устарели. Этот сервер 2008 года является последним оставшимся и поддерживает множество систем и баз данных. Кстати, ваш код работает для меня. Спасибо :)
Это очень похоже на код SQL Server, который, к сожалению, изначально почти не поддерживает поиск регулярных выражений. Таким образом, что-то вроде полнотекстового поиска или пользовательской пользовательской функции будет вашим единственным вариантом приблизиться к желаемой функциональности.