3

I'm working on getting a handle on Graph Databases (using Neo4j) and am trying to wrap my head around where "the line" is between what makes a good fit for GraphDBs and what should be strictly RDBMSs.

Particularly, I'm looking at a graph model to store manufacturing BOMs, as well as related information such as inspection reports, who invoked change orders to parts, etc. For the most part, I'm able to make this fit pretty well in the Property Graph Model.

Entities such as Part X, Engineer Y, Change Order Z are well mapped, but now I'm wondering about whether it's feasible to track inventory transactions using a GraphDB, or whether this is really a bad fit. It seems to be a bad fit, but with the alternatively seemingly to be storing data both in a Graph and RDBMSs, I'd like some further opinions.

So, I have Part A and need to track each time X amount of Part A are moved in or out of Inventory. In an RDBMs, this is of course very simple. In a Graph database, storing these transactions seems like trying to fit a square peg in a round hole.

I'm sure I can bludgeon my way through it, but what happens to my otherwise nice graph model when I start adding transactional information like this? Can a Graph DB work well with this type of data, or should I strongly consider having a Graph DB consisting of Part A with the key linked to a RDBMS that stores the inventory transactions for the given key?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.