Document databases: data model migrations

Question

Like most of us, I'm coming from a relational database world, and I'm currently looking into the possibilities of the document database world. One of my concerns is the handling of changes in the data model over time (new properties are added, properties are renamed, relationships are added, ..).

In relational databases, this is typically handled as follows:

• Write a database migration
  -> Modify the database schema
  -> Fix data for existing rows (typically contains some business logic)
  
• Modify the code (ORM updates, ..)

When using a document database, I have a feeling that changes to the data model are much easier; there's no need to update a database schema, mostly it's just adding a property, .. and everything "just works". I wonder how teams are managing this kind of migrations in real life, Enterprise projects with document databases:

• Is there a strict policy for making changes to Types that are stored in the document db? For instance, does every change to such a Type require a migration to update existing documents?
• As a consequence, is there a clear separation between the data model (types stored in the document db) and the business model?

Thanks for your time,
Koen

Answer 1

With RavenDB, you can do that with patching. See: http://ayende.com/blog/157185/awesome-ravendb-feature-of-the-day-evil-patching And: http://blog.hibernatingrhinos.com/12705/new-option-in-the-ravendb-studiondash-patching

Answer 2

There are three general strategies that you can take for "schema" modifications in MongoDB. I've seen all three work well; which one you'll use depends a lot on your particular use case.

First: you can simply add a new field to new documents, and write your code to handle the case where that field does not exist. For example, you could add an 'address' field to your "user" documents, but you'd have to write your client code to handle the case where that field does not exist.

Second: you can write your code to look at the existing document & update it when it sees an "old-style" document. For example, you could have code that checks to see if there is a "name" field in your "user" document. If it finds that field, it would split it up into "first_name" and "sur_name" fields, $unset the "name" field in that document, and $set the new "first_name" and "sur_name" fields to their calculated values.

Third: you can batch-update all of the documents in the collection to use the new schema. You'd write the same code as above, but instead of lazily applying it when your application reads a document, you'd apply it to all the documents in the collection.

Note that this last strategy can have performance impact: if you page in a lot of documents that haven't been accessed for a while, you'll put an extra load on your MongoDB system.