Has anyone ever used a graph database?

[Cayle]

I’m seriously considering dusting Angela off and using it in magicus occultus. If I do this, I’ll be going back to nosql land. It should not require too much effort to switch from my homebrew object database to something like Mongo. In fact, in certain scenarios, the nested dict returned by the PyMongo library is just what the doctor ordered. E.g. I could grab a player, all of his inventory (as well as the things inside other things within that inventory), etc. in one swoop. There are certain scenarios where Mongo’s hierarchy friendliness works against me.

For example, a player might be a member of a guild. In a relational setting, I’d add this as a foreign key to the player. If she was in multiple guilds, I’d use a bridge table. But Mongo does not have foreign keys. So if the player is in a guild, do I add the guild to the player hierarchy, or the player to the guild hierarchy? Or do I add a key value representing the faction to the player hierarchy and a corresponding key for the player in the faction hierarchy? If I go this way, A) I have to have a mess of code to re-synchronize references if I delete a player and B) I have to write a method that effectively duplicates an SQL join. So I throw the supposed performance gains out the window by writing my own, surely less than optimal, join algorithms and probably lose data integrity to boot. Yay!

Oh and that’s the simple scenario. There’s dozens more where that came from. But looking at Angela’s data model, something struck me. Yes, it’s hierarchical, but the hierarchies look different, depending on what you are currently using as your root node; whether the factor or the player is the root for example. This looks like a social graph.

I think it may be time to take a serious look at a graph database, such as Neo4j.

[a_bertrand]

I use MongoDB for Cubicverse, and for me, it is the best choice. Yet as you point out it has some tradeoff. You can't have DB handled foreign keys.

In your clan example, you may be better served by having a hint about this link in both graph:

In the player you could have a player.clans list with all the clan, and the clans could have a clans.members list with all the members. But don't store the whole graph inside the clans list or the member lists, just like the ID or name.

The main drawback of not having foreign keys is that if you delete player you will need to update manually the other list.