|Subject||Re: Full Text Search|
> Jakarta Lucene is one of the packages I have looked at, but for meThere is a C++ port, but I do not know the quality of it.
> it has a major drawback - "written entirely in Java" :)
> WHAT it is doing is no different to what we want to do. The problemEach file including its format is described on Lucene website. In
> 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 ;)
general, there are frequency files, word files, and actually index
segments (i.e. nodes).
> The only difference between Lucene and an internal full text searchThat's not true. The biggest difference is that Lucene knows what it
> is the management of the index and data.
returns as an answer to a query - document IDs. And a document is a
collection of fields. We still do not know what we want to return. Jim
claims that we should return a collection of all possible records from
different tables (e.g. one records from CUSTOMER table, two from
ADDRESS table, and so on). I'm not comfortable with this, but so far
nobody suggested any other solution.
Lester, let's assume we have this full-text feature. How do you want
to use it? Please sketch some queries.