Hi.
I have been reading the lists for couple of week now, and I noticed
people asking about placing their indexes into a RDBMS. What is the
advantage of that?
So far lucene was able to solve all my problems, but I am curious how
else people are using it (especially with RDBMS).
Having an index in the DB makes it possible to join full-text queries
against this index with some other structured queries against other table.
Here's a practical example. We have a data management system for managing
geographic metadata. Documents that we manage (geometadata) have spatial
extents (bounding boxes), temporal extents (time periods) and a lot of
textual information.
Currently, complex queries like "contains 'water*', from 1998 till 2001, in
area (5, 45, 15, 55)" can't be processed in the relational DB only or in
Lucene index only. We have to make a relatively expensive union/join outside
the Lucene and the RDB. Having Lucene index within the DB and Lucene query
(re)formulatable in SQL would allow us performing the join inside the DB
which is much more performant.
> Aleksei, can you point me to a document detailing this procedure with
> examples? If not, would you consider creating one? I am particularly
> interested in what prerequisite steps are needed to perform a Lucene query
> within SQL (if I understand correctly what you are doing).
I may be expressed myself wrong.
This idea with rewriting Lucene indexes in SQL is only an idea. There is no way
to do this currently. I just answer the theoretical question of "what the
advantage would be".
Bye.
/lexi
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
