To listen to the media, you would think that the end of the relational database is about to strike at any moment, leaving behind a shattered mess of tables and queries strewn about in proprietary servers, collecting silicon dust.
Truth be told, the future for relational databases has really never been better — though it’s a future that’s changing rapidly, altered by the ascendency of big data and non-relational databases.
In an earlier article this week, we reviewed how and when a business should consider using non-relational (NoSQL) databases. While not comprehensive, the uses for NoSQL databases center around the acquisition of fast-growing data or data that does not easily fit within uniform structures.
(See also: When NoSQL Databases Are — Yes — Good For You And Your Company)
In describing the use cases for relational databases, it would be easy to say at this point that such databases — Oracle, SQL Server, PostgreSQL or MySQL — pretty much take care of every thing else. In the broadest sense that may be true, but that’s an overly simplistic view.
Stability Is Key
First, the easy answer: relational databases are very well-suited for data sets that aren’t likely to suddenly expand. Even the most successful company, for instance, is not going to see its HR database (or an asset management database) grow faster than it can handle the new entries.
One could argue, of course, that a merger with another organization that’s at or larger than your organization could result in a rapidly expanding database. But such merger and acquisitions are rare in the course of normal business, and they are usually seen coming months in advance — which, of course, gives plenty of time to merge relational data sets.
Data in such collections is also structured, meaning that once a schema for the data is defined, (length of fields, type of data for fields, etc), data doesn’t depart from that schema. Unstructured data can include weblog information, which can be highly varied in organization, depending on what’s being monitored.
The term I usually use to describe these data set to my students is “non-exploding” data, which is colorful, but fairly apt. Data will grow and change, but not beyond the normal capability for the relational database software to keep up.
Legacy Matters
Relational databases have been around for over four decades, and that means something in the IT world.
Over those years, a lot of applications have been written to manage and manipulate data that’s been held in SQL databases — some good, some bad. But if you’re considering ripping and replacing apps or data architecture, it’s important to remember that you don’t have to fix what ain’t broke.
Yes, apps can be improved, and data schemes enhanced. Better, faster databases can be installed, too. But it may not be necessary to haul your data over to a non-relational database just because it’s new and shiny. If your workflow uses structured data, is the cost of moving to non-relational systems really worth it?
Hand-In-Hand
My favorite use case for relational databases revolves around big data.
Yeah, you read that right: big data.
Confused? Hang on a sec. See, while it is true that rapidly changing data sets do better being stored in NoSQL databases or distributed unstructured data warehouses like Hadoop, there is still a very strong and growing need for relational databases to tap into subsets of that data to perform data analysis in a timely manner.
Time after time you can read about yet-another data vendor that’s built in hooks to the rock-star popular Hadoop, for this very reason. Hadoop is great for what it does: storing data across distributed commodity servers. But for real-time analysis? Meh.
Better, then, to use a known relational database tool to create familiar queries to grab some of that data and crunch it that way you need to. This is a use case that’s growing very quickly these days, and which should keep relational database vendors in Dutch for the foreseeable future.
Image courtesy of Shutterstock.
