2009-07-29 2 views
1

У меня был рабочий запрос FREETEXTTABLE, который искал @searchString. Теперь мне нужно СОЕДИНЕНИЕ, что с другим простым запросом, который пытается разобрать @searchString в INT, и если это удастся, отфильтруйте таблицу, ища строку с PK, равную parse @searchString.Заказ FREETEXTTABLE результат UNIONed со стандартным SELECT по рангу

Раньше я мог легко ПРИСОЕДИНЯТЬСЯ к результату FREETEXTTABLE в таблицу, которую он искал, упорядочить по Рангу, но только ВЫБРАТЬ столбцы исходной таблицы, которую искали.

Теперь, когда я комбинирую уникальные результаты между текстовым поисковым запросом и запросом, ищущим строку со строкой поиска в качестве ключа, у меня больше нет доступа к Рангу из текстового поискового запроса.

Как я могу поддерживать упорядочение по рангу полного текстового поиска, но поместить результат запроса в поисках строки с первичным ключом (если он имеет результат) ДО результатов полнотекстового поиска?

ответ

0

Вы пытались просто добавить константу в свой союз, который ставит точное соответствие PK в верхней части списка? Я не помню, с какими-то столбцами столбца freetext RANK (от 0 до 1000 я думаю), но что-то вроде этого будет работать, предполагая, что вы просто сделаете свою постоянную выше верхней части ранга.

DECLARE @id int 

IF ISNUMERIC(@myStringId) = 1 
    SET @id = CAST(@myStringId AS int) 
ELSE 
    SET @id = 0 

WITH MyFreetextCte as (SELECT [Rank], 
           [Key] 
         FROM  FREETEXTTABLE(...) 
         UNION 
         SELECT 1001, 
           (SELECT MyBaseTable.PK FROM MyBaseTable WHERE PK = @id)) 
SELECT * 
FROM  MyFreetextCte JOIN MyBaseTable ON MyFreetextCte.[Key] = MyBaseTable.PK 
ORDER BY MyFreetextCte.Rank DESC 
+0

Я могу видеть действительность вашего answer-- вытягивать присоединиться от FREETEXTTABLE вызова и использования это * после * UNION. К сожалению, я не могу заставить его разбирать SQL. Это дает мне проблемы с использованием «Ранга» и «Ключа». Кроме того, если @searchString не является допустимым целым числом, будет ли CAST выдавать исключение? Первоначально у меня был блок TRY CATCH, чтобы установить значение, основанное на успешности конвертирования. Если литье прекращается изящно, я могу просто пропустить это. – Brandon

+0

вы можете обернуть эту вторую часть соединения с помощью оператора case - я обновлю пример, чтобы это отразить. Что касается не разбора запроса - я не уверен, что может вызвать проблемы ... –

+0

У меня были те же проблемы синтаксического анализа, что и тестовый запрос. Похоже, для этого нужны колонки KEY & RANK, которые нужно убрать. –

0

с тонной помощью Скотта, это то, что у меня есть, что, наконец, работает:

CREATE PROCEDURE dbo.testProcedure 
(
    @searchPhrase nvarchar(500) 
) 

AS 

DECLARE @id int 
SET @id = 0; 
BEGIN TRY 
    SET @id = CAST(@id AS int) 
END TRY 
BEGIN CATCH 
END CATCH; 
-- at this point, @id will be the primary key if it is only digits 
-- otherwise it will default to zero (which is out of range of my identity PK) 

WITH ftsTable AS (
    SELECT RANK, [KEY] FROM FREETEXTTABLE(sourceTable, *, @searchPhrase) 
    UNION 
    SELECT 1001, (SELECT sourceTableID FROM sourceTable WHERE sourceTableID = @id) 
) 

SELECT sourceTable.* 
FROM ftsTable JOIN sourceTable ON ftsTable.[KEY] = sourceTable.sourceTableID 
ORDER BY ftsTable.RANK DESC