davidrushby wrote:

>>Most database people approach search as a SQL boolean. This is too
>>restrictive to be useful. Think Google, not SQL.
>
> I know exactly nothing about full text search as implemented by
> relational database engines, so this may be a stupid question, but how
> well would a document-centric search infrastructure such as Jakarta
> Lucene (http://jakarta.apache.org/lucene/docs/index.html ) work in the
> context of a relational database engine?

Jakarta Lucene is one of the packages I have looked at, but for me it
has a major drawback - "written entirely in Java" :)

WHAT it is doing is no different to what we want to do. The problem is
HOW it does it - by building a large number of files with all the
various indexes in, and I could not work out just how many files it
needed for a simple index ;)

The only difference between Lucene and an internal full text search is
the management of the index and data.
Quote from their intro

> Did you notice what's not in the above? Lucene handles the indexing, searching and retrieving, but it doesn't handle:
>
> * managing the process (instantiating the objects and hooking them together, both for indexing and for searching)
> * selecting the data files
> * parsing the data files
> * getting the search string from the user
> * displaying the search results to the user
>

In other words it only solves half the problem, you still need to
integrate it into a usable management package. No doubt that will come,
and looking at HOW it does some of the steps may well provide guide
lines on what we need to do?

I already do something similar in php, using tables in Firebird with
triggers and UDF's to provide a subset of the functionality, but if that
was handled directly by the engine, then we can concentrate on the user
interface, rather than the plumbing, and hopefully speed performance.

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services