https://www.techtarget.com/searchdatamanagement/feature/How-to-choose-the-right-database-to-fit-your-data-models
The era of the one-size-fits-all database has been over for some time. IT shops realized years ago that not all the data their organizations needed to store, process and present to end users neatly fit into relational rows and columns.
The need to store unstructured data in conjunction with the ability to provide almost absurdly high degrees of scalability, data distribution and availability were the business drivers that led to the creation of database management systems that did not adhere to the relational model. Document, graph, key-value, wide column and other unstructured data storage technologies became viable, competitive offerings because they offered a solution to the IT community's need to store semistructured and unstructured data.
The new class of products allowed IT consumers to tailor a database engine and data model that met each application's unique storage and processing requirements. And with the increased options available, IT shops have to evaluate many things when figuring out how to choose the right database to fit their data models.
During the relational database era and the initial stages of NoSQL platform growth, most vendors specialized in one data model. Their strategy was to market their products to organizations looking for a solution that their database engine and storage model were uniquely qualified to address.
Relational and NOSQL vendors alike quickly realized that integrating multiple data models into their database engines would provide them with a distinct advantage over competitors offering a single solution.
We began to see database vendors of all types and sizes stating that their products were now able to support additional data models. We fast forward to today and find that eight of the top 10 most popular database engines ranked by DB-Engines classify themselves as multimodel.
There has been a long and lively debate on what the best strategy is to support applications that need to process different types of data that cannot be effectively stored by a single data model. For example, a retail website could potentially access a graph database for part explosions and recommendations, a document database for product descriptions, and a relational system for financial data processing.
Polyglot persistence is the strategy of using multiple databases in tandem to support a given application's need to access multiple data models. Think of it as a best-of-breed solution that uses purpose-built database platforms with each system focusing on meeting a unique set of data storage and processing requirements.
The competing strategy is to use a multimodel database, which allows the application to seamlessly access multiple data models provided by a single platform. The goal is to limit the number of data stores that the application needs to access.
Deciding how to choose the right database plan between these two options requires some consideration. Let's review the high-level pros and cons of each strategy.
My first recommendation is to understand the different data models that are available. Knowing how to choose the right database starts with understanding your database options.
In addition to the standard vendor evaluation criteria that includes company reputation, pricing, documentation and support, here is a list of recommendations to help you select a database that fits your application's data model requirements:
16 Jul 2020