TABLE 1: Comparison of Full-Text Search and a Custom Solution
Category	Full-Text Search	Custom Solution
Scaling out search functionality	You must stop the service and copy files (an undocumented procedure) or rebuild entire indexes on multiple servers.	Tables reside in database and you can replicate them to other servers by using normal replication.
Disaster recovery	You must back up search files and restore them separately; alternatively, you can rebuild indexes from scratch.	You can use normal database disaster recovery procedures.
Performance tuning	Implementation details are hidden; limited performance tuning is possible.	You can use normal database performance tuning procedures.
Data caching	In one test, full-text search went to disk 100 times for 100 identical, sequential searches.	SQL Server's query optimizer can use data cache.
Reliability	Service too busy errors could cause a complete server reboot.	Custom solution is as reliable as SQL Server.
Customizing stemming, searching for similar words (e.g., run, runs, running)	Impossible.	Possible, but requires development effort.
Performance under load	Questionable; occasional Service too busy errors.	Treats search as just another SQL Server query.
Scope of noise words	All full-text tables and searches use one noise word file.	Different searches and tables can use different sets of noise words depending on your implementation.
Index population	Several choices: log based, partial population, or full rebuilds. Repopulations can be scheduled, manually started, or background.	Flexibility requires development and testing effort depending on your implementation.
Implementation	Straightforward; includes reusable stored procedures and good documentation.	You must implement everything from scratch.
Ranking results by applicability	Possible through RANK feature.	Requires development.
Handling multiple document types (Word, RTF, HTML)	Supported well in SQL Server 2000 with document type columns.	Difficult and requires a great deal of development effort.