Thoughts on MongoDB
I just recently posted a short write up on Fluent NHibernate vs. Code First in Enterprise Library 4.1.
I’m starting up a new pet project (or rather re-starting it after a 3 year hiatus) so I’ve been trying to figure out the underlying technologies that I want to build on (as I mentioned, I’ve been in the SharePoint space for so long now, that I haven’t been up-to-date on the latest developments in DB storage). To be honest, I wasn’t really satisfied with the experience of either FNH or EF4.1, especially as I started to work with my model more and more.
What I realized is that the object-relational disconnect is still there. I’m starting to think that no amount of lipstick will make that pig presentable. It doesn’t make a whole lot of sense and is an impediment to productivity in today’s application-layer-oriented environment (if that makes any sense…); I really, really, really want to stop building database applications and focus my time and energy on the application layer.
Enter MongoDB. I think this (and the similarly JavaScript-friendly, document-oriented, seemingly less performant CouchDB) are what I’ve been yearning for in the data storage space. First, I love JavaScript; it’s my favorite language (despite whatever flaws it has) for its flexibility and dynamic nature. So the fact that Mongo’s interface language is JavaScript and that it’s data storage format is a form of JSON is really appealing to me. Second, the document-oriented nature of the storage model — combined with the JSON storage format — really goes a long way in terms of solving the object-relational disconnect because, well, the relational part is gone. You have objects and embedded objects and they map perfectly to JSON objects which in turn map fairly easily into .NET CLR objects.
Of course, one neat thing about the nature of working with JSON from UI to the database is that in some cases, the application layer can be relegated to a relatively dumb pass-through (seems like it’s still needed as one area of weakness for Mongo is authentication and authorization). Get your objects in JSON, bind to them in the browser using KO, modify them, and send them back! It’s a beautiful paradigm that could only be better with an out-of-the-box REST interface like CouchDB.
I’m just digging in, but I’m starting to think that I’m never going to look back at relational databases outside of client work and possibly as a supplementary data store for reporting purposes. It only takes a few moments to get started with Mongo so give it a shot!
