views:

33

answers:

2

Consider the following table:

People

  • FirstName nvarchar(50)
  • LastName nvarchar(50)

Let's assume for the moment that this table has a full-text index on it for both columns.

Let's suppose that I wanted to find all of the people named "John Smith" in this table. The following query seems like a perfectly rational way to accomplish this:

SELECT * from People p
INNER JOIN CONTAINSTABLE(People,*,'"John*" AND "Smith*"')

Unfortunately, this will return no results, assuming that there is no record in the People table that contains both "John" and "Smith" in either the FirstName or LastName columns. It will not match a record with "John" in the FirstName column, and "Smith" in the LastName column, or vice-versa.

My question is this: How does one accomplish what I'm trying to do above? Please consider that the example above is simplified. The real table I'm working with has ten columns and the input I'm receiving is a single string which is split up based on standard word breakers (space, dash, etc.)

A: 

http://www.developmentnow.com/g/104_2003_8_0_0_399144/Fulltext-across-multiple-columns.htm ?

eftpotrm
That's interesting, and similar to some of the other solutions I've found while searching. Unfortunately, it would require some significant rewriting for my application, and I think performance would suffer somewhat.
LockeCJ
A: 

Here's what I ended up doing:

The example I gave above might have been a bit oversimplified. In the actual application, the full-text index is actually on a view that represents a join of two tables. One advantage of this is that the schema of the view can be independent of the table(s) it is built from.

To use my (simplified) example from above, I have a table that looks like this:

People

  • FirstName nvarchar(50)
  • LastName nvarchar(50)

The view, which the index is actually built from, looked like this:

PeopleView

  • FirstName nvarchar(50)
  • LastName nvarchar(50)

To work around the problem, I modified the schema of the view so that there is now a single (plus a key) column which contains the contents of the entire table(s) represented by the view:

PeopleView

  • Name (FirstName + ' ' + LastName)

The full-text catalog had to be rebuilt, of course, taking into account the new schema of the view, but all of the changes were made at the database level, which meant no changes to the application code. I had to make a few adjustments to the view to handle columns that might have null values, since NULL concatenated with anything = NULL.

LockeCJ