Before we begin to develop an application, of any kind, any scale; we need to first thoroughly understand the requirement, to be more confident on what we are going to build. Few things we need to reflect on and evaluate at the beginning of the project – the programming language which we choose for the app, the backend architecture and framework on which the app will be built, the server on which we host and run the app, the configuration of the server and finally the choice of database and its design. The overall quality of the application, in terms of stability and reliability at varying levels of usage, is directly proportional to the above factors.
In this post, I’d be sharing few insights on making the right choice of database for your app; as storing, retrieving and updating data in a manner that the overall user experience on the app is seamless and smooth, is one of the most important challenges we need to address and solve as web developers. Whether it’s a relational or non-relational database, it’s entirely dependent on the nature of the app, data and usage.
A few years ago, when businesses were not much reliant on technology, it was enough to have a website with static data on few pages without much analytics or data mining. But today, websites and apps need visually rich – interactive pages, with a variety of fonts, videos, audios, images and deep integration with social media, to get users attention. Real-time data for decision making is becoming more important. Building websites & apps for businesses that run on technology now go through rapid changes to meet market needs.
In short, to develop products that are constantly evolving and dynamically changing, a traditional relational database fails to meet the need, as the relationships between entities are rigid, a small change in attributes / columns, require a lot of change in the Model (where the business logic resides). With a relational database, it’s very difficult to add new content, new attribute or a new feature, without disrupting performance or taking the database offline. With non-relational databases (like MongoDB), you can store any type of content, incorporate any kind of data in a single database, make changes and enhancements to the application faster.
For a marketplace portal called lawmatters.com (that recently went live), I had to store, fetch and update data for about 10 million lawyers. I used mongoDB, as querying would be faster with Mongo compared to SQL, given the volume of data I had to handle. There were few reasons why I preferred Mongo to SQL: