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 even for an Oracle table, I should think about partitioning it, which is leading to performance issues... So, maybe option a) would be a viable choice in terms of performances?
To get billions of customer--item assignments, most items would have to be assigned to most customers. How about storing only the misses? That is, for each customer store only the items they should *not* get. Or, conversely, for each item store only the customers they should *not* go to. Billions of assignments might also imply a god-awful amount of reading and parsing of the XML files.
Maybe we should take a step back up the abstraction tree. What is the access pattern for this data? Do you need random access to the list of assignments as a matter of course, rarely, or never? For example, do you iterate over the items, sending each one to each customer it was assigned to? Or, for another example, do you need to look up all the items for a customer that just logged in? Is it necessary to keep a historical record of item assignments, for how long, and in the same form as the "active" items?
--MDC --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
