Learning MongoDB: It Begins to Sink in
About the Course so Far
A true 101 course, 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-level assuming that people won’t know any of the tools. They asked us to execute commands on a terminal window and put the output in a textbox. Besides the feeling that I was 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 Learned 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 // the schema-less nature of it
d) Comparison to a relational model and how I could possibly fit it into a no-schema document store like MongoDB
My primary objective has been to build a POV that allows me to decide when to use MongoDB 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 structures like our Class Object Models. Developers have worked for some time to put in ORM tools like iBatis and Hibernate to abstract the programmer from the underlying data-models. I am not sure why we never wanted our developers to work with data-models, but Mongo will definitely take the folks away from relational models and allow them to think of objects and store them as is.
Another key aspect is if I was to architect an application (a simple layer cake design), it would be interesting for me to see where I draw the line between the conventional Services -> DataAccessor layer cake design. I look at Spring’s implementation of MongoDB and it is very different than what Spring has (or had if they have changed) for say Hibernate and MySQL. In the 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 MongoDB 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 don't 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?
a) Pretty quick to get going off the ground. I’d actually use MongoDB instead of a MySQL if I am prototyping a few things and need to use quick-start backend. (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.