Hi Ivan, Generally the denormalization strategies you might use to optimize a relational database are antipatterns when dealing with Solr, so I wouldn't hesitate to give this option a try. Solr's very good at reducing the footprint of a field value duplicated across many documents down to a simple list of those document IDs.
There isn't a good way to retrieve both sides of a join with Solr, so if you go the separate document route, you'd probably look at issuing two requests, one for products and one for packages. I'd probably use separate cores per type if you go this route. Hope that helps! Michael Della Bitta ------------------------------------------------ Appinions 18 East 41st Street, 2nd Floor New York, NY 10017-6271 www.appinions.com Where Influence Isn’t a Game On Mon, Feb 25, 2013 at 10:14 AM, ipuskaric <ivan.puska...@gmail.com> wrote: > Hi Michael, > > As I can see there are two directions how to do that: > 1) store all package data in product documents > 2) have separate documents for packages > > In reality there are lots of packages for every product. > So if I make document for every combination product+package I'll get lots of > documents that are same products and have just few fields (concerning > package) different. > If I merge data into one document type, I'll also have problems with > updating... For package changes I need to find out what products are > changing because of package change and update them. > > If I use separate documents for packages and products updating is simple, > but I'm not sure is it possible to return package data combined with product > data. > > Ivan > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Many-one-to-many-relationship-problems-tp4042700p4042758.html > Sent from the Solr - User mailing list archive at Nabble.com.
