Data Models drive how efficiently an app can not only be built, but also modified to incorporate new features. They are the bridge between the “real-world” problem that is being solved and the software world which has to emulate that real-world behavior. (Yes, software can do wonders, but no one needs software if it is not simplifying a user’s life!). This article discusses the role that no-SQL Databases play in modern software applications (a.k.a. Apps).
Over the last few years, there has been a huge shift in the choice of application development platform stacks. Traditional WAMP and LAMP stacks are being phased out with stacks like MEAN, CEAN, etc. There are many reasons for such shift. The fundamental reason, I believe, is the expectations from the modern Web. Recent expectations from the web applications has not just been limited to information delivery. Information processing and content analysis is a very key part of our interactions with web applications today. This is also often referred to as Web 2.0. Future expectations are much more as smart devices and sensors connected to internet and leverage data generated by application users to provide intelligent value-added interactions (a.k.a. Web 3.0).
This shift in paradigm of web applications demands rich data. At the same time, making data available for consumption is equally important and how just unavailable data hampers the expected user experience and application development is a topic for another day! But what’s worth mentioning here is most user-oriented applications consume and process data from multiple (data-) sources. As an extreme example, a travel booking site might have to rely on flight data as well as ticketing from multiple airline companies, credit card processing from another third party and itinerary publishing to yet another place, not to mention they also may lead users to share their booking experience on social media right from their own web application just as a part of the user’s end-to-end experience.
Well, I still haven’t brought it all together for you, have I? You may still be wondering how does no-SQL play into all of this? So, let’s get there! However it is important to understand the change that is leading us today as we start embracing new solutions from today which are in most cases created or developed because – either – it is very much required today or simply because it is possible today (in comparison to yesterday – blame it on the evolution of computer science!).
No-SQL allows complex structure
SQL databases are structured. But they also lead to some level of rigidity in handling application requirements due to its key fields, foreign key relationships, normalization techniques, etc. For example, a customer order object is often split up into header and details types of normalized table structures. No-SQL on the other hand can handle both header and details in a single structure. So, although the structure of the data model may be complex, it allows building them close to what would resemble a “real-world” entity. Of course, the cost of this ability is that the data integrity management is pushed up into the application layer.
No-SQL aligns with REST based architecture
If you have used Web Services or API’s chances are you default to JSON for the API responses (if not yet, you should try that!). No-SQL databases such as MongoDB and CouchDB store data in the JSON format (called as document). This enables coding API responses much easier in comparison to receiving them as arrays (that SQL database drivers usually return). With the higher adoption of API’s leading to highly integrated applications, no-SQL databases fit very well in terms of storing, providing and consuming information.
No-SQL brings scalability
No-SQL databases were designed ground up as multi-node databases which in turn provides great scalability features. For example, MongoDB currently can scale out to over 100 nodes spread across different data centers or locations. Many no-SQL databases also have started supporting data partitioning over multiple nodes which helps selectively scale larger data sets with larger computing resources while also reducing need for unnecessary replication and thus reducing data duplication at the cost of scalabiltiy.
These are not all, but I feel some of the key differentiators right now and while SQL databases are still catching up (which they are by the way!)
So, To-SQL or Not-to-SQL?
That really depends on the application and the use case. No, it really does, because of many factors, such as:
- The development tools and technology may not support no-SQL’s (yet!)
- The preferred vendor (preferred could be for many reasons such as strategic partnership) in your organization may still be a traditional SQL database
- The preferred database vendor may provide some no-SQL like features in the traditional database that may satisfy your current application need
- The data models may be such that there really would be no difference made by the choice
- Your position on Open Source (from enterprise support point of view)
- Your people (developers, testers, etc.) may not be skilled / trained yet
Thus, it is an architectural decision for your application to make on what kind and even which specific database you need to use. Sometimes, being cutting-edge just because…, may turn out to be an expensive affair. So, by no means the intention of this article is to influence the choice but it is more to raise awareness about this “new” widely accepted option (no-SQL) and mainly highlight the role no-SQL’s play in modern applications.
It is important to understand the expectations from today’s web applications while adapting modern technologies. Balancing the trendiness of no-SQL with the requirements, roadmaps and expectations from users (especially if it is direct user interaction) is very important. Finally, remember – requirements drive data models and data models drive choice of SQL or no-SQL. There is no wrong answer for what one may be trying to achieve!