We’ve been talking through some of the possible areas in which a document database (MongoDb, CouchDb, RavenDb) might be of use to us, and a new one came up today. The dev team were discussing database schema issues, and it seemed to me that we could bypass the entire conversation by using a schema-less database, not for production, but for testing / development.
Whilst the guys spend time refining the domain model, adding / removing attributes, changing relationships etc., the easiest thing to do data-wise is simply ignore it. Use a document database as a very simple half-way house between static mock data providers and a final-cut RDBMS (if that’s the solution). It’s also a great way to get the ops team (LOL) comfortable with using a database technology with which they are unfamiliar. No more excuses.
It’s also a neat way to remove developers from the database creation / optimisation process, should you so wish. They can ignore schema issues, and hand the problem to a database specialist. Or am I dreaming?
In addition, the ease of use means that a single dev server could be used to support multiple developers and test scenarios. Each developer could have their own database for their own abuse, and they could at the same time plug into a single, shared database for more strictly controlled test data. It would also allow testers to prime test databases with data using simpler tools than raw SQL. Everyone is a winner.
I think this probably counts as an update to this post from 2005 - http://hugorodgerbrown.blogspot.com/2005/04/unit-testing-and-data-access.html , when I’d just got the hang of the provider model.