We've done what we call phrase matching, So we take a search i.e. Project
Manager. and look at our table of phrases. if it exists we do a search on
"Project manager" or Project or manager. Project manager jobs will get a
higher ranking than those with something like you will work on a project and
report to a manager.
The challenge is building your phrase list

Signature
Simon Sabin
SQL Server MVP
http://sqljunkies.com/weblog/simons
> We've done what we call phrase matching, So we take a search i.e. Project
> Manager. and look at our table of phrases. if it exists we do a search on
[quoted text clipped - 3 lines]
>
> The challenge is building your phrase list
I'm sort of doing that now but without utilizing the full-text query:
A) I search for the exact string first
B) if there are no hits, then I split it and search again by building a
query with "AND" between all the words
C) if that fails I run the query again searching with "OR"
Before running the query, I'm also rewriting the words with some rules to
remove plurals, break up hyphenated words, etc.
If there's a hit on A, I return just that match, with the option to expand
the search, at which point I rerun the query using B, and then C.
Problem is, if A and B return no results, then C returns too many. And, of
course, there is no weighting of the search results.
Question for you Simon: Wouldn't "NEAR" achieve the same effect as a custom
lookup table?
Unfortunately the method you're suggesting in not practical for me. Unless,
I start to save all the search terms in a lookup table, and check that table
first...but that seems unwieldly, and also would seem to be replicating what
the full-text index is doing in the first place?
Or is what I'm after is beyond the capability of full-text searching?
Thanks for you comments!
>> If you know in advance all the possibilities of the search terms, I would
>> use the expansion type of the thesaurus option.
[quoted text clipped - 38 lines]
>>>
>>> Any suggestions would be appreciated!