I'm working on a project that requires me to keep track of transactions as well as the flow of items in a game. In order to do that, I'm storing those transaction in a graph db (Orient-DB).
A Shop in the game can have zero or more basekts each of which can hold one type of item. So when a Player sells something, the sold items (if any) will be placed into the respective basket and the transaction is complete.
I'm not entirely sure how to model that behavior properly though. I can think of two more or less sane ways to represent this, but don't know which representation is best for this scenario.
Things I need to know at any given time
- how did item x end up in basket y
- which transaction was responsible for that?
- which Player sold that item?
- which shops/players did item x pass through previously
- which Player did business with shop x (and the reverse)?
I create a transaction vertex and create edges between that, any and all
Basket and the
Player in question.
Downside is, I have to add data to the
contains edges, to specify which item went into which
Basket (here in light blue).
I add additional nodes, to link transactions with
Here I get to represent all data in the graph in the form of vertices and edges but I'm introducing yet more hops to get from
The downside of A that could see is that when I want to get the items of a given transaction, I have to do additional queries if I want to know how an
Item ended up in that specific
Which way should I go? Is there a better option?
Would adding a direct edge between Player and Shop be benefitial (with a reference to the transaction as property) to reduce unnecessary hops when all I want to know is, who went to a Shop?
I think this question boils down to, how many vertices are too many and when do I separate this into different queries (basically like a
JOIN in relational databases)?
I did consider a transaction log for this, but some requirements that need to be queried would make this a hell to