thanks for the quick response! that was my inkling from what i've read thus
far, but was curious if any benefits could make it potentially worthwhile.
interested in other "gotchas" the nesting may cause us to incur.
thanks again!
--
John Blythe
On Thu, Mar 7, 2019 at 10:23 AM Erick Erickson <erickerick...@gmail.com>
wrote:
> First of all, if your problem space allows it you're usually better off
> denormalizing for many reasons, not the least of which is that a change to
> any record in a parent/child relationship requires that the entire block be
> re-indexed anyway. Plus, nested docs have quite a number of “gotchas”.
>
> If you really need nested docs, your first option would require the entire
> “platonic” parent and all child docs to be re-indexed every time, so I’d go
> with 2 for that reason alone.
>
> Best,
> Erick
>
> > On Mar 7, 2019, at 10:08 AM, John Blythe <johnbly...@gmail.com> wrote:
> >
> > hi all!
> >
> > curious about how child docs and performance interact.
> >
> > i'll have a bunch of transactions coming in from various entities. i'm
> > debating nesting them all under a single, 'master' parent entity or to
> have
> > the parent and children be entity specific.
> >
> > so either:
> >
> > [platonic ideal parent item]
> > child1: {entity1, tranx1}
> > child2: {entity1, tranx2}
> > child3: {entity2, tranx3}
> > child4: {entity3, tranx4}
> >
> > VS.
> >
> > [entity1's parent item]
> > child1: {tranx1}
> > child2: {tranx2}
> > [entity2's parent item]
> > child1: {tranx3}
> > [entity3's parent item]
> > child1: {tranx4}
> >
> > could be up to several hundred child docs per entity, though usually will
> > be double digits only (per entity), sometimes as low as < 10.
> >
> > hope this makes sense. thanks for any insight!
> >
> > best,
> > --
> > John Blythe
>
>
