Learning MongoDB // It sinks in

Today I finished the 1st week of the course and as they promised it was didnt take very long – under 5 hours with what they wanted me to do (listen to lectures, answer quizzes and submit myhomework) + some other stuff I wanted to try out.


About the course so far

A true 101 courseware, and this one was even more basic – it was all about setting up the environments, running some basic commands and the quizzes were almost novice assuming that people won’t know any tools. They asked us to execute commands on a terminal window and put the output in a textbox. Barring the aspect that I am being treated like a school kid who seems to have got his hands on a computer for the first time I liked it overall.


What I learnt about MongoDB?

a) how to install it

b) how to interface with the database // add records, query records (very simple like “select *”)

c) its operating model // schemaless nature of it

d) comparison of a relational model and how i could possibly fit it into a no-schema document store like MongoDB


My Takeaways

My primary objective has been to build a POV that allows me to decide when to use a Mongo instead of a relational database. I definitely took a step in that direction. My current viewpoint is that Mongo will force us to think of data structure more close to what our Class Object Models are. We have strived for some time to put in ORM tools like iBatis and Hibernate to abstract the developers from the underlying data-models. I am not sure why we never wanted out developers to work with data-models, but Mongo will definitely take the folks away from relational models and allow them to think of objects as store them as is.


Other key aspect is if I was to architect an application (a simple layer cake design), it would be interesting for me to see where do i draw the line between the conventional Services -> DataAccessor layer cake design. I looks at Spring’s implementation of the Mongo and it very different than what Spring has (or had if they have changed) for say hibernate and MySQL. In past Spring had a clear distinction of what a DataAccessor is and what a service is and the demarcations of Transactions etc. Spring’s implementation of Mongo is pretty simple and almost unilateral when it comes to layers that define – so much so that the lines between the Service and Access are blurred and I struggle to define if i even need it.


As for modelling (which will remain key), unlike in RDBMS where we have a normal form and rules in place and where a 1st normal form was almost bad, and 4th normal form is where we wanted to go, Mongo will leave the modelling (of whatever schema it has) to the logical thinking of the application. It is my understanding that the balance of modelling the “collections” will rely with Application Architects (not with DBAs). It might be too early to say, but it seems that we need to design for “fast reads” and we aim to put whatever data we can in a dictionary that can hold all of it. The interesting aspect is when you need to see the data from another dimension. Here is an example (building upon what was presented to me course). The course is asking me to create a web application that is a blog basically. Keeping other stuff aside, we have “Post” and every post has “Tags”. As a requirement we need to show all tags for a post next to it and also for a tag as we can show all posts.


We all know a many-to-many relation in a relational database will do this trick for us, but in a document database we put (or so was I asked) Tags as a array in the Post Object itself. The power of it was now i dont need to join the two tables and the retrieval is super fast but now when I need to meet my need for getting all Posts for a given tag or if i need to change the name of the Tag globally – what was supposed to be a simple label change in RDBMS now becomes a marathon. As for the later case, I was arguing how many times does that really happen (aka change tag labels) but the first one is pretty important for my blog requirements. The course didn’t answer that one. They explained the benefit (no join hence fast fetch) and left it at it.

I start off the Week 2 tomorrow and I will want and see if they actually explain some of these over the course of the classroom else I will go about digging? Would any of you know?


Key Takeaways

a) Pretty quick to get going off the ground. I’d actually use this one instead of a mysql if i am trying a few things and need to use quick-start backend. (where in production – i don’t know yet)

b) If you are taking this course be mindful of not making judgements on the technology or how you’d want to use it especially model your schemas (or shall I say documents). Wait for the now or go and read more.

3 thoughts on “Learning MongoDB // It sinks in

  1. It’s really a cool and helpful piece of information. I am satisfied that you shared this
    helpful information with us. Please keep us up to date like this.
    Thanks for sharing.

Initiate your idea here...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s