Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tree mapping in Moqui #49

Open
mckhoi opened this issue Jan 15, 2021 · 2 comments
Open

Tree mapping in Moqui #49

mckhoi opened this issue Jan 15, 2021 · 2 comments

Comments

@mckhoi
Copy link

mckhoi commented Jan 15, 2021

Hi,

some algorithm need to fetch the whole tree structure e.g. the BOM(Bill of Materials) to analyse some sort of KPIs in planing, forcasting in production. The BOM in real life sometimes can be big. My question is that, whether moqui can connect to a graph database to map the whole BOM or a really good mapping algorithm to persist the whole BOM for easily fetching?

My first thought is about running mysql and orientdb(neo4j ...etc.) in parallel?!?!
Second thought is adaopting technique like that https://typeorm.io/#/tree-entities also in moqui framework?
1. Adjacency Lists - https://schinckel.net/2014/09/13/long-live-adjacency-lists/
2. Many many other idees?

Thanks
Best regards,
Khoi Tran

@jonesde
Copy link
Member

jonesde commented Jan 15, 2021

This is more of a discussion than an issue, and is more related to mantle-udm (the data model) than PopCommerce.

No such requirements have yet come up but the plan for hierarchical data is to use something like the Closure Table pattern which can be used with any of the join entities in UDM, including ProductAssoc that is used for BOMs. To do this only one field needs to be added an integer field for closureTableLength that is null if Closure Table style additional records are not being maintained (making the model flexible and the feature optional).

There are other entities that use a self-reference for the parent instead of a join table, like WorkEffort. In that case we use a simple optimization to get a full tree without recursive queries by adding a rootWorkEffortId field in addition to the parentWorkEffortId field.

At one point I did some experimenting with OrientDB which has a graph database, but I have yet to come up with a use case for it for any client I'm working with (ie real world demand, not speculative or lacking resources to back) that is poorly handled by a relational database to the point that it is worth having yet another external system dependency. It's bad enough depending on a relational database plus ElasticSearch!

@mckhoi
Copy link
Author

mckhoi commented Jan 15, 2021

Thanks for your quick anwser. I played a little bit with neo4j, but I do not have any clue, whether it is a good fit with moqui or not.
Please let me know, if you already have some sort of external system dependency with graph databse in mind.
I just find a list of them, https://www.predictiveanalyticstoday.com/top-graph-databases/

Thanks in advance, David.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants