Reflections on MongoDB
We have used MongoDB on several production and play projects over the last year. We love it. MongoDB is now the default database for new projects at Collective Idea.
There will be blood
But before I get too far, let me be clear: MongoDB is not all leprechauns and unicorns. It’s the bleeding edge, and you will bleed.
The libraries and frameworks are still immature. There are some awesome libraries in development, but if you’re coming to them from a mature library like Active Record, then you’ll find them lacking (nothing a little sweat and blood can’t fix).
As a result of immaturity, there is a lack of curated documentation. The wiki on mongodb.org has some great information that will get you started, but there isn’t much beyond that. As Mongo gains traction, that will change.
There is no spoon
Our industry has accumulated 40 years of relational database theory. If something can be modeled in a relational database, then somebody has done it, and there is generally consensus on which way is the best.
But everything we know about modeling is tied to relational databases. We split out our data structures into third or fourth normal form (there are normal forms that are too complex for mere mortals), and then create models that directly map to those structures. We rarely consider how the data will be used when designing the database.
With document databases, the approach is exactly opposite. Figure out how the data will be used, then figure out how to structure it. There is a distinct moment of epiphany when you realize that you don’t have to create a separate collection just to store repeating phone numbers, or add a join table to associate an article with multiple categories.
It’s not the Wild West
While RDBMs are great for storing data, it turns out they are actually horrible application development platforms (are there any Oracle developers in the house?). And for too long, vendors tried to push application logic into the database. Many Rails developers realized long ago that specifying application constraints in the database is actually a bad idea. Among other reasons, it leads to errors that are extremely difficult to present gracefully to the user.
MongoDB is a “schema-less” database, meaning that it doesn’t care how you structure the data that you put into it. Some worry that schema-less databases are too out-of-control, like you’ll wake up one morning to find your user records have become mutants.
Having a schema-less database does not mean your application is schema-less. It just means that we are choosing to specify our entire schema in our application, where we were already defining constrains on our schema.
When should I use MongoDB?
OK, I think MongoDB makes sense with most web applications. In the end, most apps are just doing glorified CRUD, and don’t need ACID or many of the features of a relational database.
There are times when you definitely should not use MongoDB, like when you need transactions. Document databases are shiny and new (to most of us–others have been using them for 20 years), so we’re still figuring out how to model things. Conventions are emerging, but de-normalization and application-driven design make it difficult to apply universal patterns.
If you haven’t checked it out yet, I highly recommend it! If you have, then share your thoughts and experiences in the comments.