Re: Best design for an use case which is going to stress Lucene

Terenzio Treccani wrote: You're both true, this doesn't sound like Lucene at all... But the problem of such SQL tables is their size: speaking about millions of customers and thousands of news items, the many-to-many (CustArt) table would end up by containing BILLIONS of lines A bit too big

Re: Best design for an use case which is going to stress Lucene

You're both true, this doesn't sound like Lucene at all... But the problem of such SQL tables is their size: speaking about millions of customers and thousands of news items, the many-to-many (CustArt) table would end up by containing BILLIONS of lines A bit too big even for an Oracle table, I

Re: Best design for an use case which is going to stress Lucene

This doesn't sound like a Lucene problem, at least the way you've described it. For example, Lucene can't search on any field that isn't indexed (and most of yours aren't indexed). Given that, it seems like your option (c) is the way to go. Seems like a simple RDBMS schema with 3 tables woul

Re: Best design for an use case which is going to stress Lucene

> No queries on other fields (news metadata etc) will be performed. Do you mean that a full text search on the news text isn't required? I might be wrong, but it seems to me it doesn't sound as a typical Lucene usage.. I'd go for the (c) option.. (but not just one table :-) Bye, Fabio P.S.: how

Best design for an use case which is going to stress Lucene

Hi all, I'm required to develop an application for searching over news items. There will be thousands of news items, each one will be assigned directly to a list of millions of customerIDs. The query will be done by passing a customerID and will return all news items associated to it. Furthermore,