Beginnings of a new MOO: The first obstacle.

So, I've started a GitHub project and have put some code in it. So far, I have a few basic types in static Python, that implement some simple features, like "look".

The next steps (moving around, creating new objects) all require some kind of object persistence, so that is my next step. It's a pretty big step as well, since I need to decide on an data model.

Relational model:

I can be relational, each item is a row in a table, its properties and methods, etc of in other tables, with relations compiling everything together for me. In this case, I'd probably use PostgreSQL, since it's nice and fast compared to other relational DBMs.

Document model:

The document model treats each object as a document, with various free-form fields. The benefits of this over relational databases is that you don't have a in-database schema to modify. In CouchDB, the documents are accessed over REST and JSON (much like the rest of the MOO is in RESTMOO), so it seems like a fairly appropriate choice.

How does one decide?

We have to figure out what our data looks like. We have objects. These objects have properties and verbs. These objects should also probably be able to inherit properties/verbs from eachother. I don't think any of the features of our dataset exclude either storage paradigm, so performance must be considered instead.

Performance:

In the relational model, when we do a property or verb lookup, we have to check the object and its parents (I'd like to do multiple inheritance, so this branches insanely), which as far as I understand (I am no master of relational databases) is a shitton of fairly complex JOINs.

In the document model, I fetch the document I'm looking for a property/verb on, if it's not there, I check the first parent if it's not there I check the first parent's first parent, continue on through the inheritence tree until I find whatever I'm looking for. This sounds like I'd be making a bunch of subsequent REST calls, except CouchDB allows you to create Javascript "views" – methods that take a document argument and do some work for you, returning your results.

SQL is FAST, Javascript seems like it would be slower, but on the other hand our data more closely matches the document model, so there's no object-relational mapping to be done by the Javascript, just the hunting for our inherited methods/properties. I think I'm in a pickle – I think I have no choice but to build both and see how they perform.

UPDATE:

I've chosen to use a document model. The model more closely matches my data, and even if lookups are slower than their equivalents in the relational model, I believe that the document model will provide better scalability (Master to Master replication under relational databases is a pain).

Also, writes to a document database will be simpler, since inheritance won't be a factor (only bottleneck in the document model), while in the relational database even writes will require JOINs (although simpler/fewer than when reading).