Powerful e-commerce software needs an underlying database that enables an optimal data flow, no matter how much load is on the system. Intershop relied on Oracle for a long time, but with MSSQL another database can be the basis of an Intershop Commerce solution.
Custom-fit software is the basis for a powerful online shop. What is the problem of committing to one database provider?
If you are committed to one provider, then that means being dependent. Of course from all the positive features, but also from company decisions such as licensing model changes. For a long time, Intershop has relied on Oracle, at least for its commerce management.
Our Order Management System is based on PostgreSQL, our microservices can be deployed to any database. But our core product required Oracle. This is because Intershop products have always been developed for the enterprise market, and we selected Oracle as the leading database provider.
Today, most customers do not start from scratch, but already use database systems based on MSSQL for example. These companies already have personnel who are experienced in the administration of these systems. So it is a major hurdle to gain know-how for Oracle.
Our core product, Intershop Commerce Management, is no longer based on Oracle. What are the alternatives?
A few years ago there were phases of evaluation which DB systems are strong enough in terms of their performance and features to support software for high-performance online shops. The first step was to opt for PostgreSQL, but it never went beyond theoretical considerations.
Intershop is now a Microsoft Gold Partner and offers a dedicated cloud offering on Azure. The enterprise market is also increasingly relying on Microsoft products. So it is only logical to support the Microsoft database.
Following a successful PoC, a task force was set up in Munich to develop a first prototype. Special thanks go to Daniel Heckmann, Ulrich Neidel and Franz Robeller from MS, but also to Carsten Polack and Thomas Bergmann, who made this project possible. The prototype allowed great confidence to adapt our software so that MSSQL can be supported on an equal footing with Oracle.
How can such a change in the software be imagined?
Well, all databases basically speak SQL. However, there is a very high variability here, with different words and concepts.
In the past, Intershop relied on special Oracle features, for example, XML was stored in the database and accessed in a structured manner. With MSSQL this is also possible, but it differs how this access to data works.
Creating tables in the database and the types that are processed there are all things that work differently with various providers. But as long as relational databases are concerned, the underlying basis is defined by similarities. We needed to make many small and bigger changes in the code, both complex and filigree at the same time.
However, our code also contains elements which only indirectly affect the database, but are nevertheless specific. Drivers for example. Most of our software is written in Java. This means that we can, in general, work independently of a database. The SQL for the database can be generated with queries and thus tailored to specific database functionalities.
Does this lead to a loss in performance?
The question is justified. A generic database query is certainly not the optimal or the fastest one. It is no coincidence that database providers have developed their products in such a way that particularly demanding jobs also have special high-performance queries. You can't use these details if you're always looking for the smallest common denominator.
So our way was to continue to be able to address these peculiarities. But large parts of the code have been adapted so that generic database-independent SQL queries can be used. The neuralgic points, however, have now been newly developed with different queries that are specially adapted to the Oracle or the MSSQL databases. In this way we continue to benefit from the specialties of both DB systems.