Nowadays, when creating a business application or modeling our Data Warehouse, we no longer have to assume that a relational database is our only option. A relational database probably will be the best option, but not the unic.
Let’s turn back the clock to December 2006. Neal Ford writes an article in his personal blog where coin the term “Polyglot Programming”. In his article he says applications could be written in different languages, taking advantage of the benefits of each of them, depending the problem to solve; Ford had planted the seed. Two years later the concept of “Polyglot Persistence” appears in the Scoot Leberknight’s personal blog.
“Polyglot Persistence” is a reinterpretation of “Polyglot Programming” and, just like it, proposes us to use the right type of persistence for each data and application
Let’s look at the classic example of an online store, where the information is not uniform. We could persist our information in different ways:
- Transactional, customer and financial data could be stored in a relational database. This type of structured data, where it’s not possible to lose any transaction, needs the
capacity of a relational database.
- “Shopping Cart” data in a document-oriented or key-value database, because these applications need a rapid access to this kind of data and is deleted once the purchase
process has finish.
- Product recommendation module in a graph database. Graph databases give the capacity to create relations between entities quickly and without the need of modify
Therefore, the market offers multiple solutions for our data persistence, let’s take the advantage of correct choice for any requirement.e.
Up to here everything suggests: Why am I not using this paradigm yet? there are many issues to consider: multiple databases management and the cost associated and the complexity to
make all databases work together. Apply security policies to data access working with different database engines could be a big headache.
For this reason, “Polyglot Persistence”, although not being a new concept, it doesn’t have a big acceptance, despite being the perfect solution: use the right database for each use case.
That is why a new concept was born that Oracle has already begun to implement: “Multimodel Polyglot Persistence”, as opposed to the “single model” approach.
This approach consists in giving the capacity to work with different persistence models to the database engine in an isolated and separated environment. Thanks to this capacity, user
management, security policies and database management doesn’t duplicate,
From the version 12, Oracle offers the capacity to store data in different modes: relational, key-value, XML. Json, graph and spatial.
For more information: Multimodel Database White Paper.