What’s your SLA? It seems that you have two problems - finding correlated information that’s in a hierarchy and potentially displaying it.
I feel your desire to conflate the two is forcing you down a specific path. Often times in complex scenarios I’ve found that an index like Solr is better for the search and not necessarily the storage or display. The question I have is : what’s your application workflow? Who is querying this data? How are they expecting to see it? How fast do they need that data? I understand what you’ve described (which seems to be a non functional requirement ) of what you want to do but in order to help it would be helpful for me at least to know how the data is ingested, Enhanced, and retrieved. In terms of data volume, you may consider indexing all data , but not storing all of it. This makes sure you aren’t duplicating data that isn’t an awful waste of space. Rahul Singh Chief Executive Officer m 202.905.2818 Anant Corporation 1010 Wisconsin Ave NW, Suite 250 Washington, D.C. 20007 We build and manage digital business technology platforms. On Sep 11, 2018, 11:23 PM -0400, John Smith <localde...@gmail.com>, wrote: > On Tue, Sep 11, 2018 at 11:05 PM Walter Underwood <wun...@wunderwood.org> > wrote: > > > Have you tried modeling it with multivalued fields? > > > > > That's an interesting idea, but I don't think that would work. We would > lose the concept of "rows". So let's say child1 has col "a" and col "b", > both are turned into multi-value fields in the solr index. Normally in sql > we can query for a specific value in col "a", and then see what the > associated value in col "b" would be, but we can't do that if we stuff the > col values in multi-value; we can no longer see which value from col "a" > corresponds to which value in col "b". I'm probably explaining that poorly, > but I just don't see how that would work.
