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
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.