When comparing results of SQL's Full-Text Catalog
to the IIS 6.0 Index Server to ANY other commercially
available vendor's offerings, like a Lexus-Nexus search
or Imceda Software or DeiselWorks, which produces
the fastest indexing and the fastest query results
for multi-word searches across a diversified document
type set including PDF's, Word, Text, XML, HTML, etc.?
Price may not be an object for a commercially viable
solution that runs with or without an Oracle or a SQL Server back-end,
using Sun or Intel Servers with either a Java or
an ASP.NET GUI. In other words, neither operating system
nor licensing, nor database, if required, is an issue and
for the right solution, while price is always a consideration
no vendor will not be considered if it offers only a high
end Enterprise Solution. Assuming that the disk subsystem
selected is held constant across all vendors.
Please respond via eMail as well:
jfbevilaqua@yahoo.com
Thanks.
Hilary Cotter - 27 Aug 2005 22:43 GMT
As you want to compare Database Search engines with SQL FTS engines, I am
going to assume the choice of document repository is irrelevant.
For pure querying and indexing speed and nothing else (no property
indexing/querying no advanced querying features) nothing beats FAST. Fast
however requires an index which is at least the same size of the data you
are indexing.
http://www.fastsearch.com/
Also high up there is Thunderstone.
Once you start factoring in features and restricting the choices by OS, I
think you will find that the search engine in SQL 2005 offers the best
choice, especially if you need real time indexing.

Signature
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
> When comparing results of SQL's Full-Text Catalog
> to the IIS 6.0 Index Server to ANY other commercially
[quoted text clipped - 18 lines]
>
> Thanks.
Simon Sabin - 19 Sep 2005 13:54 GMT
You also need to consider interop with your application code. Also need to
consider where your data resides, how you want to update and how frequently
and finally how you want to support it.
If speed is the only requirement then you can or course ignore all the above
but be warned.
> As you want to compare Database Search engines with SQL FTS engines, I am
> going to assume the choice of document repository is irrelevant.
[quoted text clipped - 34 lines]
>>
>> Thanks.