lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shah, Vineel" <vin...@hotjobs.com>
Subject RE: custom scoring api questions
Date Thu, 02 Jan 2003 16:19:23 GMT
It's not a bad thought. We're using Oracle and usually would just do a SQL query and let Oracle
indices take care of the searching. However:

1. One of the fields is a clob with >16k of text per entry. We're using Oracle's Context,
which has proven unreliable and slow.
2. We have to search on a normalized data structure. Each parent row may have 10-100 child
rows.There may be up to 200,000 parent rows. There may be 60 query terms to look for in the
child rows. In my inherited codebase, the query does 60 joins against the child table for
each parent. Needless to
say, the web page times out before the search is done. Our users are understandably frustrated.

And so, it seems worthwhile to use a seperate search engine and sync the database contents
to it. I looked at Lucene because it is open source, in java, low overhead, and fast. So far,
I'm extremely pleased with the results!

vineel

-----Original Message-----
From: Leo Galambos [mailto:galambos@com-os2.ms.mff.cuni.cz]
Sent: Tuesday, December 31, 2002 5:16 PM
To: Lucene Developers List
Subject: Re: custom scoring api questions


On Mon, 30 Dec 2002, Shah, Vineel wrote:

> I've been developing a search function with Lucene for a couple of weeks
> (it's wonderful!) I've run into a snag-- the way I need to calculate
> scores seems to have nothing to do with Lucene's scoring paradigm. I
> think this is because I'm doing a database-oriented search instead of a
> document-oriented one.

Isn't it better to use RDBMS with B+? I am not sure if a fulltext module
is a good way... Just a thought... :)

-g-



--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>

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