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
On Tue, Sep 11, 2018 at 11:05 PM Walter Underwood
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
On Tue, Sep 11, 2018 at 11:00 PM Shawn Heisey wrote:
> On 9/11/2018 8:35 PM, John Smith wrote:
> > The problem is that the math isn't a simple case of adding up all the row
> > counts. These are "left outer join"s. In sql, it would be this query:
>
> I think we'll just have to conclude that I do
Have you tried modeling it with multivalued fields?
Also, why do you think Solr is a good solution? What is the problem?
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Sep 11, 2018, at 7:35 PM, John Smith wrote:
>
> On Tue, Sep 11, 2018 at 9:32
On 9/11/2018 8:35 PM, John Smith wrote:
The problem is that the math isn't a simple case of adding up all the row
counts. These are "left outer join"s. In sql, it would be this query:
I think we'll just have to conclude that I do not understand what you
are doing. I have no idea what "left
On Tue, Sep 11, 2018 at 9:32 PM Shawn Heisey wrote:
> On 9/11/2018 7:07 PM, John Smith wrote:
> > header: 223,580
> >
> > child1: 124,978
> > child2: 254,045
> > child3: 127,917
> > child4:1,009,030
> > child5: 225,311
> > child6: 381,561
> > child7:
On 9/11/2018 7:07 PM, John Smith wrote:
header: 223,580
child1: 124,978
child2: 254,045
child3: 127,917
child4:1,009,030
child5: 225,311
child6: 381,561
child7: 438,315
child8: 18,850
Trying to index that into solr with a flatfile schema, blows up
>
> On 9/7/2018 7:44 PM, John Smith wrote:
> > Thanks Shawn, for your comments. The reason why I don't want to go flat
> > file structure, is due to all the wasted/duplicated data. If a department
> > has 100 employees, then it's very wasteful in terms of disk space to
> repeat
> > the header data
On 9/7/2018 7:44 PM, John Smith wrote:
Thanks Shawn, for your comments. The reason why I don't want to go flat
file structure, is due to all the wasted/duplicated data. If a department
has 100 employees, then it's very wasteful in terms of disk space to repeat
the header data over and over
Thanks Shawn, for your comments. The reason why I don't want to go flat
file structure, is due to all the wasted/duplicated data. If a department
has 100 employees, then it's very wasteful in terms of disk space to repeat
the header data over and over again, 100 times. In this example there is
On 9/7/2018 3:06 PM, John Smith wrote:
Hi, I have a document structure like this (this is a made up schema, my
data has nothing to do with departments and employees, but the structure
holds true to my real data):
department 1
employee 11
employee 12
employee 13
room 11
Hi, I have a document structure like this (this is a made up schema, my
data has nothing to do with departments and employees, but the structure
holds true to my real data):
department 1
employee 11
employee 12
employee 13
room 11
room 12
room 13
department 2
employee
12 matches
Mail list logo
