I’m currently working on a FIRST scouting data management project in my spare time. The requirements I’m working with are fairly well-defined, but the statistics collected change from year to year. I want to be able to use the same software year after year and keep historical data intact. I’m using Django for the front-end, but instead of using a traditional SQL database, I’m experimenting with using MongoDB, one of those new, fancy No-SQL databases.

MongoDB is prominently used in SourceForge, Foursquare, Diaspora, and a whole slew of other nifty websites, but I have resisted until now because I haven’t had a compelling reason to not use a SQL database. The basic premise of MongoDB is that instead of rows, it stores collections of JSON dictionaries that can be queried with (you guessed it) more dictionaries. Inside of each dictionary, you can store any value, including other dictionaries (inside of a dream inside of a matrix inside of a dream, as South Park would say). The upshot is that with very minimal code, you can execute complicated queries that immediately return usable objects—no need for an ORM.

The major hurdle that I came across was that Django does not support using MongoDB as a backend. It’s annoying, but I don’t need too many of Django’s advanced features for this project. I’ve pieced together a form generation class that can automate many of the nitty-gritty details of going between the Django form API and the underlying MongoDB I/O, much like Django’s ModelForm does.

On the whole, working with MongoDB is a pleasure. Yes, the programmer has more responsibility for sticking to a consistent schema, but if done properly, MongoDB can be a powerful tool. I wouldn’t recommend it for every project, but give MongoDB a chance.