I know that a SQL Server full text index can not index more than one table. But, I have relationships in tables that I would like to implement full text indexes on.
Take the 3 tables below…
Vehicle Veh_ID - int (Primary Key) FK_Atr_VehicleColor - int Veh_Make - nvarchar(20) Veh_Model - nvarchar(50) Veh_LicensePlate - nvarchar(10) Attributes Atr_ID - int (Primary Key) FK_Aty_ID - int Atr_Name - nvarchar(50) AttributeTypes Aty_ID - int (Primary key) Aty_Name - nvarchar(50) The Attributes and AttributeTypes tables hold values that can be used in drop down lists throughout the application being built. For example, Attribute Type of ‘Vehicle Color’ with Attributes of ‘Black’, ‘Blue’, ‘Red’, etc…
Ok, so the problem comes when a user is trying to search for a ‘Blue Ford Mustang’. So what is the best solution considering that tables like Vehicle will get rather large?
Do I create another field in the ‘Vehicle’ table that is ‘Veh Color’ that holds the text value of what is selected in the drop down in addition to ‘FK Atr VehicleColor’?
Or, do I drop ‘FK Atr VehicleColor’ altogether and add ‘Veh Color’? I can use text value of ‘Veh Color’ to match against ‘Atr Name’ when the drop down is populated in an update form. With this approach I will have to handle if Attributes are dropped from the database.
— Note: could not use underscore outside of code view as everything between two underscores is italicized.
I believe it’s a common practice to have separate denormalized table specifically for full-text indexing. This table is then updated by triggers or, as it was in our case, by SQL Server’s scheduled task.
This was SQL Server 2000. In SQL Server you can have an indexed view with full-text index: http://msdn.microsoft.com/en-us/library/ms187317.aspx. But note that there are many restrictions on indexed views; for instance, you can’t index a view that uses OUTER join.