Hi.

As one of the people who asked about placing indeces into RDBMS, I was
primarily interested in just storing index in the RDBMS (basically,
storing the structures described on this page
http://lucene.apache.org/java/docs/fileformats.html in the relational
DB). The main reason is NOT to be able to perform some magic with
joining Lucene and 'pure DB query' results (which, actually, IS useful
in some curcumstances, but don't really see a problem of doing it in
Java after quering DB and Lucene), but rather avoid the cost of
reindexing and associated problems in complex enterprise environments.

There no problem joining/intersecting Lucene/DB results in the Java layer apart from performance. Imagine you have 10k results from Lucene and 10k results from the RDB and you only need results 20...40 ordered by 'name' field, ascending (which is the usual case). An sql query with join and limit/offset would be much faster than joining 20k entries in Java.

Yet another advantage of storing index in the DB is its 'managability'
and 'debugabiliy' (nice word!). Through there is Luke, etc,
administrators in big companies do not want to learn many new tools and
having smth already familiar to deal with can sometimes be a good
argument in favor of product adoption. (BTW, Compass, as Aleksei
mentioned, can be the answer to this prayer - meant to check it out long
time ago, but haven't got around to it yet. Also, it seems like the
project is half-dead. I wonder if it's true...)

Compass is a lively and active project, we successfully use it in production.

Bye.
/lexi

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to