Being Non-Relational

When I saw the first version of Majikal, it looked like the biggest challenge of my professional life. It was little better than ancient mainframe model to start with. The only good part was data interchange format (JSON) that made me believe I was looking at 2011 codebase.
MySQL database or any relational database for that matter is a good choice to build enterprise products where the requirement is not so dynamic as it is in the modern days. Whenever there is change in domain model, you need to make a lot of code change to support the backward compatibility. The ORMs present in the market are not really masking the complexity. As you know Database has strong influence on domain model, many domain objects make more complex mapping joins in RDMS and that will make the queries even harder to write. I also had to write lot of boilerplate code to map the JSON APIs to the normalized domain model. What if JSON was our primary model?
I started looking for document based databases. CouchDB was simple keystore, it gives great flexibility on schema design front but leaves a lot on developer to implement the domain model. Cassandra, on the other hand offers huge scalability but schema design was way too difficult. I found mongoDB quite upto the requirements as it was simple to use and can execute similar queries to RDBMs. On one hand it can store JSON natively.

One of the challenges that comes with moving to MongoDB is figuring how to best model your data. While most developers have internalized the rules of thumb for designing schemas for RDBMSs, these rules don’t always apply to MongoDB. The simple fact that documents can represent rich, schema-free data structures means that we have a lot of viable alternatives to the standard, normalized, relational model. Not only that, MongoDB has several unique features, such as atomic updates and indexed array keys, that greatly influence the kinds of schemas that make sense.