Has anyone ever used a graph database?
Posted: Thu Feb 06, 2014 1:40 pm
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.
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.