contantable検索の書き方

Question

現在、aで選択されたステートメントを書き込もうとしています containstable そして、検索条件は私に悲しみを与えています。

目的は、3つの異なるパラメータータイプでテーブルを検索し、それに応じて出力をランク付けすることです。 （以下は私のコードのサンプルです）

1. キー検索条件（必須アイテムと1で重み付けされています） || testvalue = Accountant
2. 追加の必需品（加重.8） || testvalue = Manager
3. 持っていてうれしい（加重.5） || testvalue = Excel

SQL：

 SELECT KTBL.Rank as [Ranking], KeySkills
   FROM Applicants INNER JOIN 
      CONTAINSTABLE(Applicants, KeySkills, 
        '(ISABOUT("Accountant" weight(1))) & 
         (ISABOUT("Manager" weight(.8))) | 
         (ISABOUT("Excel") weight(.5)))
     AS KTBL
   ON Applicants.Id = KTBL.[KEY];

上記の声明は何も返さず、上記の方法で条件を積み重ねることができるかどうかを疑っています。

返された結果は会計士とマネージャーの両方を持っている必要があり、Excelを持っているといいでしょう

私がこれを達成できるようにするための提案はありますか？

Answer 1

私は最終的に、当面が満足しているという自分の質問に対する解決策を思いつきました。

以下に示すように、3つのパラメーターを取る（少し長い巻き上げ）に示すように、ストアドプロシージャになりました1.プライマリ検索キー（一致する必要があります）2。追加のコンマ分離文字ストリング

CREATE PROCEDURE [dbo].[GetJobSeekers]
(
@KeywordSearch nvarchar(500),
@MustHave nvarchar(500), --Comma separated skills
@NiceToHave nvarchar(500) --Comma separated skills
)
AS
BEGIN

SET NOCOUNT ON;

DECLARE @SQL nvarchar(4000)
DECLARE @SELECT nvarchar(4000)
DECLARE @SEARCH nvarchar(4000)
DECLARE @SEARCH1 nvarchar(4000)
DECLARE @SEARCH2 nvarchar(4000)
DECLARE @WHERE nvarchar(4000)
DECLARE @ORDERBY nvarchar(4000)

/*Used for string split*/
DECLARE @POS int
DECLARE @NEXTPOS int

/*Get Result for primary search key*/
SET @SELECT =   'SELECT ktbl.rank AS [Ranking], jobseekers.*'
SET @SEARCH =   'ISABOUT("'+@KeywordSearch+'" weight(1))'

SET @WHERE  =   ' FROM jobseekers INNER JOIN
                CONTAINSTABLE (jobseekers, *, ''' + @SEARCH + ''')
                AS ktbl On jobseekers.Id = ktbl.[KEY]'

SET @ORDERBY=   'ORDER BY [Ranking] DESC'

/* Get Result set for all additional must have keywords and INNER JOIN With primary Search */
IF @MustHave <> ''

BEGIN
    DECLARE @MustHaveSplitString nvarchar(500)

    SET @POS = 1
    WHILE(@POS <= LEN(@MustHave))
    BEGIN
        SELECT @NEXTPOS = CHARINDEX(N',', @MustHave,  @POS)
        IF (@NEXTPOS = 0 OR @NEXTPOS IS NULL)
              SELECT @NEXTPOS = LEN(@MustHave) + 1
        SELECT @MustHaveSplitString = RTRIM(LTRIM(SUBSTRING(@MustHave, @POS, @NEXTPOS - @POS)))

        SET @SELECT = @SELECT + ', ktbl'+@MustHaveSplitString+'.rank AS [Ranking'+@MustHaveSplitString+']'
        SET @ORDERBY = @ORDERBY + ', [Ranking'+@MustHaveSplitString+'] DESC'
        SET @SEARCH1 = 'ISABOUT("'+@MustHaveSplitString+'" weight(.8))'
        SET @WHERE = @WHERE + ' INNER JOIN CONTAINSTABLE (jobseekers, *, ''' + @SEARCH1 + ''')
                                AS ktbl'+@MustHaveSplitString+' on Jobseekers.Id = ktbl'+@MustHaveSplitString+'.[KEY]'
        SELECT @POS = @NEXTPOS+1    
    END 
END


/*Get result set for all nice to have by stacking them in the isabout searchcondition and LEFT OUTER JOIN with Primary Search + Must have search if its there*/
IF @NiceToHave <> ''
BEGIN
    DECLARE @NiceToHaveSplitString nvarchar(500)        
    SET @SEARCH2 = 'ISABOUT('

    SET @POS = 1
    WHILE(@POS <= LEN(@NiceToHave))
    BEGIN
        SELECT @NEXTPOS = CHARINDEX(N',', @NiceToHave,  @POS)
        IF (@NEXTPOS = 0 OR @NEXTPOS IS NULL)
              SELECT @NEXTPOS = LEN(@NiceToHave) + 1
        SELECT @NiceToHaveSplitString = RTRIM(LTRIM(SUBSTRING(@NiceToHave, @POS, @NEXTPOS - @POS)))

        SET @SEARCH2 = @SEARCH2 + '"'+@NiceToHaveSplitString+'" weight(.5),'            

        SELECT @POS = @NEXTPOS+1    
    END         
    /*Clean last , off the search2 string */
    SET @SEARCH2 = LEFT(@SEARCH2, LEN(@SEARCH2) -1)
    /*Close the isabout in search2 string*/
    SET @SEARCH2 = @SEARCH2 + ')'


    SET @SELECT = @SELECT + ', ktbl2.rank AS [Ranking2]'
    SET @ORDERBY = @ORDERBY + ', [Ranking2] DESC'

    SET @WHERE = @WHERE + ' LEFT JOIN CONTAINSTABLE (jobseekers, *, ''' + @SEARCH2 + ''')
                            AS ktbl2 on Jobseekers.Id =          ktbl2.[KEY]'
END

SET @SQL    =   @SELECT + @WHERE + @ORDERBY

EXEC sp_executesql @SQL
END

ストアドプロシージャは、追加のロジックを考慮する必要があるため、まだ100％完了していませんが、当面は最終結果のシェルとして機能します。また、私はこれをかなりの量のデータに対してまだテストしていないので、それがどれだけうまく機能するかはまだわかりません。

敬具、