Hi we can query multiple tables in a full-text search by using views ,but we some advantages and disadvantages .
Here in your case you created view dbo.vw_recipe_search it seems your are not using it in altered procedure when i query it i am getting results as per intended
SELECT *
FROM dbo.vw_recipe_search r
INNER JOIN FREETEXTTABLE(vw_recipe_search, *, 'salsa peas') kt
ON r.search_id = kt.[KEY]
ORDER BY RANK DESC;
The problem in this approach is ranking and weightage of each column , like suppose if u want to give high weight to title column than descrip you have to do a lot of work in order by rank column .
We used Levenstein string comparision function to order for better results set
Hmm I'm afraid '#' counts as punctuation and SQL Server Full-Text Indexing was invented before Twitter. There are however a couple of approaches:
1) Pre-processing
Use the full-text functions to fetch most of the data then refine it with Like
, eg
SELECT Id
INTO #tmp
FROM dbo.Users
WHERE CONTAINS ( Bio, '#promoter' )
SELECT *
FROM dbo.Users u
WHERE u.Bio Like '%#promoter%'
AND EXISTS ( SELECT * FROM #tmp t WHERE u.Id = t.Id )
Whilst you could use CONTAINSTABLE
to do the same thing in one query, you can't necessarily guarantee what order the plan will take - and why
would you, T-SQL is after all declarative. I prefer to be explicit, but if you find performance acceptable and/or data volumes are low, combine the two, eg
SELECT *
FROM dbo.Users u
INNER JOIN CONTAINSTABLE ( Users, Bio, '"#promoter"' ) ct ON u.Id = ct.[key]
WHERE u.Bio Like '%#promoter%'
I did some simple tests on a 1 million row table and it seemed to perform ok. YMMV.
2) Tokenised version of column
Store an alternate version, eg a computed column where '#' is replaced with the literal text 'hashtag', something like this:
-- Add computed column
ALTER TABLE dbo.Users ADD cleanBio AS REPLACE ( Bio, '#', 'hashtag' )
-- Add the computed column to full-text index
ALTER FULLTEXT INDEX ON dbo.Users ADD ( cleanBio )
GO
SELECT * FROM dbo.Users
WHERE CONTAINS ( cleanBio, 'hashtagpromoter' )
Obviously there is some storage overhead here.
Consider trying these approaches with your data and let me know how you get on.
Best Answer
You may want to just leave it as users enter it, since you can safely use strings processed twice via
quote_literal
. In theto_tsquery
documentation, the example for phrases within ts queries is:Adding some junk to the phrase breaks it, unless you pass it twice via quote_literal, which makes any string safe to use: