The Genesis of the Multimodel Database
The possibility of multimodel databases was never contemplated until fairly recently. Such an idea – a database that could manage all data structures rather than focusing solely on a particular subset of data structures – was, for decades, believed to be impractical. Over the last 25 years, relational databases dominated, despite the fact that they could only accommodate data that was shoehorned into tables. They proved capable of handling most OLTP applications and most data warehouse applications, and where their rigid adherence to tabular data structures led to problems, those issues were circumvented by programming techniques: stored procedures, object-relational mappings and so on.
While relational databases were the dominant database products, they were not the only ones. Some niche database products offer far superior support for recursive data structures, nested tables or graph data. They found use in situations where the performance requirements for managing such data was paramount. Database species have been increasing at a steady pace in recent years. A list of the “newly evolved” includes: XML DBMSs, column stores, document DBMSs, time series DBMSs, graph DBMSs, multivalue DBMSs, RDF DBMSs, event stores and key-value stores.
Common sense dictates that no business will want to house such a diverse variety of product types. Consequently, a “consolidation trend” is emerging, with some database products adopting a multimodel approach – a database that physically stores a wide variety of data and supports multiple data models. One such database is FairCom’s c-treeACE.
Download the Full Report
Download a complete report and get the full analysis from the Chief Analyst of the Bloor Group, Robin Bloor.