This is fairly timely as I'm investigating possibilities for our data model and graphdb just popped up on my radar. Are gdb good for modeling multiple types of products? Let's say v1 of product has attributes a, b, c but v2 now adds x, y, z and removes a. Would that be 2 separate nodes?
I too am interested in understanding the downsides of a gdb (seeing some refs to performance but nothing concrete).
Graph db's are a very good idea. Its just that the solutions in the market are not very mature yet, and the community is not very large yet. Most of the downsides stem from these two facts.
So unless the solution you're building has a specific need for graph queries - in particular, complex, realtime and ad hoc graph queries, a traditional solution is a safer bet.
You can make v1 and v2 two separate nodes, if you need information of both of them. In this case you just link each version to its attributes.
If you want the "latest" marked separately, you can have three nodes - one for "current", and the other two for the individual iterations. So initially "current" would link to a,b,c and later link x,y,z, and remove a.
Or, you can have two nodes - current and previous iteration, and store the version number of the latest iteration as a field within the "current" node.
Comments
This is fairly timely as I'm investigating possibilities for our data model and graphdb just popped up on my radar. Are gdb good for modeling multiple types of products? Let's say v1 of product has attributes a, b, c but v2 now adds x, y, z and removes a. Would that be 2 separate nodes?
I too am interested in understanding the downsides of a gdb (seeing some refs to performance but nothing concrete).
Graph db's are a very good idea. Its just that the solutions in the market are not very mature yet, and the community is not very large yet. Most of the downsides stem from these two facts.
So unless the solution you're building has a specific need for graph queries - in particular, complex, realtime and ad hoc graph queries, a traditional solution is a safer bet.
You can make v1 and v2 two separate nodes, if you need information of both of them. In this case you just link each version to its attributes. If you want the "latest" marked separately, you can have three nodes - one for "current", and the other two for the individual iterations. So initially "current" would link to a,b,c and later link x,y,z, and remove a. Or, you can have two nodes - current and previous iteration, and store the version number of the latest iteration as a field within the "current" node.