lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson" <erickerick...@gmail.com>
Subject Re: a question about indexing database tables
Date Thu, 22 Feb 2007 12:54:25 GMT
don't do either one <G>.... Search this mail archive for discussions of
databases, there are several long threads discussing this along with various
options on how to make this work. See particularly a mail entitled
*Oracle/Lucene
integration -status- *and any discussions participated in by Marcelo Ochoa.

But, in general, Lucene is a text search engine, NOT a RDBMS. When you start
saying "keep all relation in order to get right result", it sounds like
you're trying to use Lucene as a RDBMS. It doesn't do this very well, that's
not what it was built for. There are several options...
> get clever with your index such that you don't do anything like join
tables. This implies that you re-design your data layout, probably
de-normalizing lots of data, etc.
> Use a hybrid solution. That is, use Lucene to search text and then do
whatever further relational processing you need in the database. You need to
store enough information in the Lucene documents to be able to query the
database.
> stick with a database if it works for you already.

In general, it's a mis-use of lucene to try to get RDBMS behavior out of it.
When you find yourself trying to do this, take a few minutes and ask
yourself if this design is appropriate, and continue only if you can answer
in the affirmative...

Best
Erick

On 2/22/07, Mohammad Norouzi <mnrz57@gmail.com> wrote:
>
> Hello
> In our application we have to index the database tables, there is two way
> to
> make this
>
> 1- index each table in a separate directory and then keep all relation in
> order to get right result. in this method, we should use filters to
> overcome
> the problem of searching on another search result.
> 2. joining two or more tables and index the result of join query.
>
> which approach is better, reliable, has acceptable performance.
>
> thanks
> --
> Regards,
> Mohammad
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message