Years ago, while doing my university course for DBMS, I used to have a whole book talking about Relational Theory & RDBMS. I was lucky that the alternative models were also discussed in a couple of lectures – where my professor took keen interest to discuss hierarchical models, network/graph based models and columnar models.
And now, when I started learning MongoDB I realized that there are a few things I will have to unlearn. 3 concepts that form the foundation of Relational Database but that had major limitations like –
1) Normalization is the way to achieve flexibility:
Being a Database Architect for the initial 3 years in my career, I have had arguments with Application Developers who wanted to add new fields in existing tables. And I would say, “To keep our design flexible we need to have a normalized table and store this info as ‘PhoneNo’ and ‘PhoneType'”. This had many times impacted the delivery schedules. But there was huge gap in what Business Analysts, Developers and Database Architects thought about ‘flexibility-in-design’.
2) Joins help us combine multiple entities:
While I was working as a Development DBA, people used to look for me to help them write join queries. I would write a query which joins PhoneDetails twice with CustomerDetails to get phone number information for Mobile and HomePhone for a customer. I thought that’s the power of JOIN. Whereas in developer’s perspective, CustomerDetails is an object containing array of PhoneNumber as a member. There was a divide in the way DBAs and Developers perceived ‘entities’.
3) Foreign Keys help us maintain integrity of system:
When you have 2 entities ‘CustomerDetails’ and ‘PhoneDetails’ one might end up retaining an entry in PhoneDetails while removing record from CustomerDetails. To avoid these anomalies, Relational Database Theory offers the concept of Referential Integrity or Foreign Keys. But won’t it be too much of work to delete each and every dependent record before I can finally delete a record from CustomerDetails?
Once I realized these limitations in fundamental concepts of Relation Database Theory, it became easier for me to understand and grasp the notation of schema-less or flexible schema design in MongoDB.
The nesting and array support within a JSON document enables one to query all the data from a single collection without needing JOINs. Since all the data can be stored together it will be removed together, hence doing away with the need of Foreign Key for integrity check. And this is all possible by dropping the need for normalization. And guess what, you don’t have to compromise on flexibility either. You can very well have a new record which has other type of phone numbers.
I have come far from being that university student and today I see the world has come far from relying on just tables of rows and columns.

– Sameer Kumar I Senior Solution Architect, Ashnik

Other Articles in the newsletter:
The ‘Big’ Announcement – Sachin Dabir
Internet of Things, Data explosion and Databases of the Future – Michael Santana
Guest Article: Future Talk – Rohit Rai, MongoDB Director Sales