The polyvalent database design of the future
It is not a question of either-or, but both-and, when it comes to choosing between RELATIONAL AND NOSQL DATABASES. So say database expert Martin Fowler and his colleague Pramod J. Sadalage in a book that includes focus on the 'PolyglotPersistence' approach.
NoSQL databases have attracted a great deal of attention in a very short time. Hailed by some as the solution to database challenges of the future, and hated by others as unnecessary technological obstructions. Whether you are for or against the NoSQL systems, the huge amount of hype has led to the erroneous conclusion that the relational database, after 20 years of dominance, is on its way to extinction. It certainly is not, says database guru Martin Fowler in his book 'NoSQL Distilled', which he penned together with his colleague Pramod J. Sadalage.
Martin Fowler and Pramod J. Sadalage describe how there are still many tasks that relational databases solve much better than NoSQL databases. In addition, NoSQL database technologies are still very immature. There are many edges that need to be sanded down before they achieve the same streamlined usability level as relational databases. Just as there are still many more tools for relational databases than for NoSQL databases. In other words, relational databases will continue to be the preferred database type for many tasks. But prompted by the emergence of NoSQL databases, , the default approach to database systems has been given a shake-up.
A few years ago, the starting point was always: Which relational database should I use for this specific task? Or an even worse alternative: You must use this relational database for this specific task, because that is the one we use in this company! These boundaries are softening up, argue Fowler and Sadalage, so that the starting point today is more along the lines of: What is the most suitable technology for my specific task? It is only when you know the answer to that question that you are able to select a product regardless of whether it belongs to a group of relational or NoSQL databases. The authors call this new approach the 'PolyglotPersistence' approach.
Polyglot solutions
'Polyglot' means multilingual, or a person who can speak several languages. And that is exactly what the future within database design offers. Applications should be based on several different languages??, say Fowler and Sadalage, so you can take advantage of each database system's ability to solve a challenge. If there is anything we have learned from the past decade and its not only increasing amounts of data, but also more and more complex data structures, it is that there is no one-size-fits-all solution. Complex applications require correspondingly complex solutions to the reciprocally interconnected issues.
This applies not only across the application layer in a business, but also to each individual application. A complex enterprise application currently already uses many different types of data and also integrates data across sources. This reality will be reflected in an increasingly polyglot design of future applications, according to Martin Fowler and Pramod J. Sadalage.
(See the above figure.)
Complexity brings challenges
Complexity is synonymous with new opportunities. But complexity is also synonymous with new challenges, warn Fowler and Sadalage. For each completely new unknown NoSQL database you introduce into a business, many human resources and development hours are needed to learn the technology properly. Many of the NoSQL databases are also designed to run on large clusters, which for some companies means that they suddenly have to deal with issues of data consistency and availability in a whole new way.
There are more than enough challenges, according to Martin Fowler and Pramod J. Sadalage, who also offer a word of advice on the types of database projects that lend themselves to a 'PolyglotPersistence' approach.
If a distinction is made between between strategic database projects and routine database projects, NoSQL projects are most suitable for strategic database projects. There is no reason to bring so many unknown factors into play with a routine project that does not have the potential to add value to the business. On the other hand, a strategic database project based on the 'PolyglotPersistence' approach will help to significantly increase the productivity of developers and thereby also increase the time-to-market. A 'PolyglotPersistence' approach may also prove beneficial for very data-intensive projects where there is a lot of data traffic and high availability requirements.
Fumbling their way
What should you take away from this review of the polyvalent database design of the future? You should be aware that many NoSQL databases are still relatively immature technologies compared to relational databases, and therefore we are in a phase where many are still fumbling their way in the dark. You should also be aware that this fundamental uncertainty should be factored in if you are considering using, or advising others to use a mix of relational and NoSQL databases. You must also be aware that the concept of 'PolyglotPersistence' does not stand unchallenged in the industry. Many professionals oppose Martin Fowler and Pramod J. Sadalage's way of thinking and call 'PolyglotPersistence' a short-term approach to the problem. Critics argue that the polyglot design leaves software developers with a bigger headache than they started with. They would rather see developers tackle the challenges of building the necessary data models based on a single architecture, instead of integrating several different ones.
