Join works best with a small number of unique values. Unfortunately, people often want to join on <uniqueKey>, which is by definition unique per document.
The usual advice is to first try to flatten your data as much as possible. There's also some ongoing work on "block joins" that you may want to look at the JIRA for, explicitly for parent/child relationships but I confess I haven't a real clue what the details are.... Best Erick On Mon, Aug 20, 2012 at 2:56 PM, Steven Livingstone Pérez <webl...@hotmail.com> wrote: > Hi folks. I read some posts in the past about this subject but nothing that > definitively answer my question. > I am trying to understand the trade off when you use a large number of fields > (now sure what a quantative value of large is in Solr .. say 200 fields) > versus a join - and even a multi value join. > The reason being, I have a document that has a set of core fields and then a > load of metadata that is a repeating structure. > D1 F1 F2 F3 F4 F5 ..... S1a S1b S1c S2a S2b S2c .... > I'm not sure whether to create a load of fields up to SNx and a single > document or to have multiple documents with each SNx in a separate document > with a parent id that points to a parent document (or a multivalue metadata > pointer field). > I hope that comes across reasonable well - please ask if not. Oh, if anyone > knows of any quantative studies in Solr fields/documents i'd love to see the > hard stats to improve my knowledge. > Loving Solr. > Cheers,/Steven
