Johannesburg, 15 Feb 2022
Data is fundamental to your business competitiveness, right? After all, this is what we're told repeatedly: data enriches our understanding of our customers and operations, creating insights that we can use for research, development and strategy. Yet this logic can encourage companies to think that more data and better insights are mutually exclusive, which is inaccurate. You can sit on a lot of data and not gain much currency from your information stockpiles – especially if your databases don't support your data strategies.
Data needs a database, and a database should be fit for purpose, explains Marius Huysamen, Big Data Technical Team Lead at software solutions design firm, Obsidian: "Your database choices should be discussed as part of a data strategy tied to business strategy. It's not like the old days where you get quotes from three big vendors and choose one. There's more to it. Depending on your business needs, you need to pick the right database."
New space for databases
Organisations are often wary of disturbing their databases. Since these carry valuable data, they are treasure troves and losing a database is often devastating. But as we increasingly rely on data to power our applications and inform business processes, we need responsive databases.
Very often, the performance of an application (and thus the subsequent impact on customer or user satisfaction) depends on how fast and flexible a database is. It's thus essential that business decision-makers have a sense of why databases are important and how one type of database is not a fit for every situation.
We can generally split databases into two camps, Huysamen explains: "There are many types of databases. But in most cases, you want to know the difference between relational and non-relational databases. Relational databases are what most people think of: they are structured into tables and ordered through linked relationships with other tables – something that can look a little like a spreadsheet, though more intense and elaborate. Relational databases are great for organising data, but they don't scale well because, as your database grows, you need more power to manage the various relationships.
"Non-relational databases do not use structured tables or a predefined structure and you use something such as JSON scripts to create and query entries. They can scale better and work well when you have a lot of unstructured data. But they are not that useful if you work with defined data sets."
Choosing the best database
Non-relational databases, sometimes also called No-SQL, are very popular because they are well-suited for large data sets and cloud-native use cases. This creates the impression that relational databases are outdated, but Huysamen disagrees: "There is still a need for relational databases. Most businesses have a front office system – maybe an online retail store – and a back office, which will have analysis of the sales data and such things. You can also use embedded databases on IOT devices. In most cases, companies will need at least two types of databases. It's not just about the centralised system."
This is the conversation that companies need to have: for the best performance, databases need to be fit for purpose. If you process too much data for your relational database, it will become cumbersome and require more server power. But if you require support for structured data sets, non-relational databases will require more effort than necessary.
Some modern databases blend the two models, offering relational features that can still scale, and hybrid database ecosystems are also gaining ground: for example, using non-relational databases with relational database languages such as SQL, or vice versa. Beyond that, there are other choices such as graph databases or cache databases, each doing specific jobs in a data value chain.
All these choices can be daunting, which is perhaps why companies don't want to mess with their databases. Huysamen notes that you have to be diligent; your IT estate will become more complicated as you add databases and start duplicating data. He concludes: "Databases are a technical topic, but make the effort to find out where they fit into your data strategy and business requirements. If you treat them as an afterthought or a static asset, you can end up with more complexity and poorer performance. And also think about control; whether you rent, partner or own to get a database, ensure you maintain control of your data and don't get locked in."
Share