No problem - it’s a real shame as I love the technology - and would have considered supporting it in other ways, if we’d been given the opportunity.
If you need a hand here or there, I may be able to to point you in the right direction (he said, modestly - my modesty’s my strongest point). Bottom line is DGraph has the same issues as any other graph database from an analytics perspective.
Some of our common bits:
We added edges to help us group and aggregate - avoid facets for this type of activity as you tend to trip over yourself later.
We also found it useful to use the target node type as a component of the name in edges - it makes analytics much more specific and lets you have explicit queries following known node/edge paths. Invoice_LineItems and Basket_LineItems can both ‘point’ to LineItem types, but you know absolutely what you’re asking the analytics tools to pull out.
We also did explicit definitions for reverse edges - every edge was defined - reverse edges can lose their meaning when you try to do a reverse-edge lookup in something like Qlik. Much better to define them both explicitly.
Again, from a distinct perspective, we found it better to use intermediate nodes with edges pointing to the ‘real nodes.’ We could query the intermediates, and still get to the real nodes, if needed.
Probably teaching you to suck eggs here - apologies if that’s the case.
Best of luck with your project.
Mike