Over seven decades of computer science, we've come to accept a world of trade-offs: Systems that work great within a narrow band of use—for example, storing years with two digits, and the infamous 640k limit (who would ever need more?). While these system shortfalls are ancient history in computing terms, we still deal with similar limitations today; they’re just less obvious.
One such issue is our blind adherence to the relational database format. I admit, it's flexible, and it's easy to think in terms of tables and relationships. But this often leads to headaches, with painful reindexing and schema updates that show the inflexibility of the format.
In addition, IT often deploys heavy, overcomplicated RDBMSes to serve very simple data needs, which leads to poor resource utilization.
A classic tale of software engineering goes like this: A project manager talks to the business stakeholders and develops specifications (the engineering team might even be in the room for this meeting). Afterwards, engineering takes this specification and creates a beautiful piece of software that encapsulates all the points in the specification and even anticipates some future features.
They take the software to the stakeholders and show off their elegant creation until they hear the phrase, "Why can’t we just change this little part to do … ?" At that point the engineering team goes pale and cancels its project victory lunch to rip out the best code it's ever written and replace it with bodges to get the job done.
Let's assume that everyone involved is competent and well-intentioned. Finger-pointing is natural, but is anyone really to blame? Probably not. Here's why.
Rise of the multi-model database
Thankfully, we're at the dawn of a new era: the multi-model database. This model refers to one database server that you can use in different ways (models). Unfortunately, while many multi-model databases are available today, the concept of multi-model is not yet well defined, so it means different things to different people.
The relational/tabular format is one model. However, even when the database server can do many different things, if the data itself is still siloed, you'll be stuck when presented with "Why can't we just … ?" problems.
A true multi-model database allows your data to be manipulated in different ways.
While many people have tried to take a single model (relational/tabular) and use it for various things, a true multi-model is about using the best model to fit your use case.
The tree-of-life example
Take, for example, a simple tool that lets you analyze all the world's life arranged by biological classification (e.g., seeing that a human is in the phylum of Chordata and the class Mammalia). This tree of life maps naturally to a graph database model, which allows for queries about the relationships between data.
From the perspective of building a clean application around this data, graph processing makes a great deal of sense. Imagine a stakeholder saying, "Why can't we just have a description field ... ?" No problem. "... that we can search?" Problem.
Graph databases aren't designed to handle full-text search queries. Say someone wants to find all nodes that contain the word "house" or "domestic" and the word "cat," but also wants to analyze the relationship between these and nodes that contain "dog" and "wild."
Graph databases are designed to find nodes and relationships, not to find text. On the other hand, search databases can't easily find the relationships between documents.
This is a classic example where a database that can operate in multiple models at once is needed. This would allow the same data to be indexed for full-text search, and by node and relationship to the rest of the graph. What's more, it wouldn't require you to duplicate the data or keep two distinct systems running.
Explore the possibilities
Of course, this is just one use case. Think about the possibilities of having full-text, searchable time series data, or a graph that knits together key-value binary blobs.
The database of the future will head off problems by being flexible enough not to lock you into choices that were made in the absence of perfect knowledge or the privilege of final review. And as an added bonus, future multi-model databases will allow you to pick the most appropriate model for different uses, enabling better resource utilization and easier development.
Keep learning
Get up to speed fast with TechBeacon's guide to the modern data warehouse.
Download the Buyer's Guide to Data Warehousing in the Cloud.
Get up to speed on digital transformation with TechBeacon's Guide.
How important is digital transformation to your org? Take our survey and find out how you stand next to the competition.
Thinking of making a change? TechBeacon's Careers Topic Center provides expert advice to prepare you your next career move.
