SQl, noSQL, and Doctrine with Symfony 2.0

Question

I've had the idea of creating a webgame for a while now, and as it becomes more and more accurate i started playing around with Symfony 2.0.

First question :

it seems that it is recommanded to use Doctrine2 (ORM) to manipulate database with Symfony, but i'll feel more comfortable with pure SQL. Am i wrong ?

Second question :

The game i'm thinking of is somewhat a kind of RPG, with the classic character, stats, inventory, etc.

I have some notions of SQL, and i'm improving my knowledge of it at school right now (though i deplore they only teach us oracle environment), but there's a point i need to discuss : How would you modelise the character's inventory ? Is a noSQl databse (mongoDB) usefull here ?

Answer 1

I don't have the exact answers you're looking for, but I'll just lay some options out there.

1. I'm biased, but I would say that you definitely want an ORM instead of dealing with SQL directly.

   • If you're into the whole OOP thing, then an ORM gives you an object-oriented view of your data, which is usually more helpful than manually pulling data out of rows and stuffing it into records in some weird, custom way that gets smeared all over your sprawling game architecture. Centralize your storage access and Don't Repeat Yourself.
   • A well-written ORM layer gives you a lot of flexibility down the road if you need to switch DB platforms (Oracle to PostgreSQL, or something).
   • You will, inevitably, need to write custom SQL at some point. That's okay, it doesn't mean the concept of ORM is faulty... it's just not an airtight abstraction.

   Check out this article on the "Active record pattern" to see what else it gives you. It's a very common architectural pattern for writing ORMs.

2. As far as modeling a character's inventory, you'll probably end up with something like this: make Characters, Items, and ItemTypes tables. Each row in Items has the primary key of the row in Characters that the item belongs to (Targ, the barbarian, has this particular sword). Items also has the primary key of a row in ItemTypes corresponding to the type of item it is (this sword item is of type sword).

   That might not be parseable as English. What I mean is, you don't want to duplicate the attributes of the sword item across every character, monster, and dungeon in the world. You're probably much better off making every individual sword item point to a "sword type" and then, when you need to adjust the attributes of swords (and you will), you can change it in one place and BAM, it's changed everywhere.

   You could extend this to the characteristics of items as well: maybe "of Lightning" is a characteristic that can be added to lots of stuff: weapons, armor, clothes, whatever. So, "of Lightning" gets its own row in the SpecialTypes table and your lowly sword, from the Items table, now points to "of Lightning". BAM, one Sword of Lightning coming up.

   That all makes more sense if you're modeling this stuff relationally. If you were going the NoSQL route, then you might be better off denormalizing everything into the character object. But I'll let someone else tackle that. ( ;