I am developing some kind of web-based RPG. So for my player domain I came up with this.

player object is going to have a lot of parameters like class, level, name and so on. As it rather plain object I store it in the relational database like PostgreSQL for example. I have an entity RPlayer for that.

Also I wanted to introduce for the player the ability to make contacts with other players - some basic feature of social network. For that reason I decided to use graph database like Neo4J. I have an entity GPlayer for that. It is simpler object with some unique fields like id or name.

As object became somehow distributed - I keep the data for it in different storages - I added mapping of id in RDBMS to id in graphDB. In the end it looks like this. (I don't know how to add fields in draw.io to table so I have only three fields here and name is missing).

enter image description here

I didn't connect players and mapping table as one of the fields is external so I had no reason to connect relational_uuid to id in players table.

When I need to retrieve everything - I merge all the data from GPlayer - player representation is graph - and RPlayer - player representation is the table - into CompletePlayer object that contains all the fields from both objects.

enter image description here

When I add new player

1. I create record in app.players table and get r_ID
2. I create node in graphDB and get g_ID
3. I create record in util.mapping for r_ID and g_ID

Also those 3 steps I am planning to do in scope of global transaction.

Does such approach is ok? Should I somehow store domain in the single database and not spread it across different storages?

  • Do you have a specific reason to store it in two databases? Is there a reason to use a graph db? You can store relationships (like comrade) in a relational database - that's what they're for. – doubleYou Nov 29 '17 at 18:37
  • You mean to use the table like playerId, playerId, relation? Also I have always thought that RDBMSs are not used for social networks. – lapots Nov 30 '17 at 7:55
  • 1
    Yes, a comrades table that stores (PlayerId, PlayerId) records. If you want to know the comrades of player x, this is enough. If want to perform complex operations on the graph of comrades-connections, something else might be better. Anyway, this is a topic for another day (maybe another question), so I've answered your question under the assumption that you do need both DBs. – doubleYou Nov 30 '17 at 18:26
  • For now I just want to implement the ability to make a player a friend and remove if needed so plain table is enough. I see. – lapots Nov 30 '17 at 18:29

In principle, you're not wrong (assuming you really do need separate databases). A few possible improvements:

  • Unless you have a specific reason for it, you should probably not store the player's name in the graph database, just the IDs and relationships between the players.

  • If every player is going to be associated with exactly one entry in each database, there's no need for a mapping table. Just use the same Id for both. If you cannot use the same Id in both databases (for some reason), store the Id created in one database as a field in the other database's records: e.g. store g_Id as part of a player record.

  • It might make sense not to merge the information into a single object, but rather to only retrieve the player object and then have a ComradesService or some such thing that you can use to obtain information about relationships.

Especially the last point depends a lot on what you're really using the graph DB for. However, if the information you retrieve is reasonably complex, loading it every time may not be wise. If it is simple (e.g. just who's a comrade of whom?) then you might be better of getting rid of the graph DB altogether.

Finally, if you have to do complex graph queries, but also have a simple feature like the one mentioned above, you could replicate the simple information in the relational DB.

| improve this answer | |
  • What If I use playerName as id for both graph and relational DB? Because it should be unique anyway so there might not need to introduce separate ids. – lapots Nov 30 '17 at 18:28
  • Yes, that should work fine. – doubleYou Nov 30 '17 at 18:35

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.