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:[EMAIL PROTECTED]] 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
