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)?

Option A:

Option A

I create a transaction vertex and create edges between that, any and all Items, the 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).

Option B:

Option B

I add additional nodes, to link transactions with Baskets and Items. 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 Shop to Player.

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

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 JOIN

  • I'm not entirely sure I understand the background to this question - are you using a graph database, or are you using graphs as an abstract model of the process, or something else? – Jules Mar 15 '16 at 19:29
  • @Jules I am using a graph database (Orient-DB) and want to store those transactions. Will update the question to make this clearer - thanks for pointing it out – Brunner Mar 15 '16 at 19:31

A day after posting the question, I came to the realization that I was holding the problem wrong. My question about adding an edge between Shop and Player was already a step in the right direction.

I don't need to solve my three problems with one graph structure.

When querying how an Item ended up in a Basket, the transactions are only secondary. The important part is the "flow", which I can easily traverse when there's a link between the Basket and the Item.

Also, when I want to know the shops frequented by players, I just need to add an edge to that. If I want to know more details about a specific transaction, I can always query the referenced Items.

Lastly, a short representation of the model I ended up using:

Solution graph

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.