On jeu, 2003-02-27 at 10:50, Eric Jain wrote:
Hello,
Sorry for this late answer.
Just some remarks from my own experience with DBs & full-text indexes.
Maybe I'm totally wrong for your case.
>
> 1) For further filtering the full text search results using data only
> available in the database. While this data could be duplicated into the
> index, this wouldn't always be effective, e.g. for range queries. The
> index would have to be updated more frequently. Also, in some cases I
> already have the query system set up to use the database, and would just
> like to add the full text search option as an additional constraint.
>
I can not tell for you but in my case putting the important attributes
in the index was the best solution. Updates are not so frequent and
anyway Lucene permits incremental modifications (I asynchronously
updated the index whenever the DB is modified). If your indexes change a
lot sorting and merging two ID lists (one from the index and one from
the DB) in Java space will certainly be the most effective solution.
> 2) The user may decide which fields he wants to have displayed, in the
> worst case all matching documents may be downloaded completely. This
> would require duplicating all data into the full text index, slowing
> down the indexing process.
That's the easy part. Once you have the document IDs you can always
retrieve the data from the DB (if you paginate the results you even only
have to retrieve the data page after page).
>
> 3) For sorting search results according to user defined criteria,
> currently this is not feasable with Lucene if you are working with a
> large set of documents.
This is the hard part in any retrieval system. If the sorting
attributes are not too big I still would extract them with the IDs and
do the sorting in Java space. If they are really big the TMP table you
choose is certainly the best option.
Cheers,
Dom
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
