Relational vs. Relational

There is an old quote attributed to various origins that says, “When I hear the word ‘culture,’ I reach for my gun.” The saying expresses frustration at a term, in this case “culture” being used, abused, and politicized beyond all forbearance.

Even when it was first popularized, it was a line meant to draw laughter from the audience of a play, rather than suggesting anyone carry an actual firearm. And no one is suggesting anyone do so now. “Relational” is a term that, over the last few decades, has undergone its own level of use, abuse, and politicization. It seemed every couple of years, one vendor or another would start ringing bells, hawking for market share, heralding a new tool, a new idea, a new approach … and this new, shining, bright whatever was killing off relational databases and replacing it. Ding, dong, the king is dead.

Only, it never really happened.

The reasons for this lack of relational database replacement by a new sovereign are many. First, vendors were often under the belief that a tool is a tool, and therefore a new tool will often replace an old tool. And that kind of an opinion does often prove to be true. Audiotape recorders, 8-tracks, VCRs, cathode ray tube monitors, and Super 8 movie cameras have all come and gone.

The misstep by these vendors praising the new king is in thinking of a relational database as simply a tool. The relational database is an implementation of an idea. It is because of this idea–implementation relationship that so many differing relational database products exist in the market.

As well, it is because of this relationship that replacing relational theory, which is the foundation underneath all those relational databases, means finding a newer and better logic—set theory and predicate logic. The logical foundations have almost never been under attack.

Individual implementations may falter and fade, but the idea, the theory, remains. Often, vendors proclaim a new ruler by simply addressing a new ad hoc implementation that often has no theoretical foundations to begin with. Figuring out that side of things, the foundational logic is left as a later step rather than a first one.

Relational theory means the user of the database may treat data as tables and columns, and that concept is the bedrock. Some relational database vendors chose to implement internal operations as tables and columns too, but that internal realization was never the requirement.

How things work behind the scenes was always expected to advance and morph over time along with the advancement of technology.

In fact, a tool can be a “relational database” even when options exist such that different groups of data are stored in drastically differing configurations using vastly differing algorithms to access and retrieve the data, just so long as the user still thinks of the data as if it were tables and columns.

Therefore, at least in my mind, for the cornucopia of new database tools that arose under the onslaught of “Big Data,” as each of those products added in user interfaces allowing people to write SQL and treat the data as tables and columns, each became a relational database.

The necessary interactions between a tool and the foundational theories each tool is implementing are often ignored. The theory behind many tools and products we use is considered the hard part we had better just ignore. Some people accidentally confuse the two ideas, and others confuse them purposefully. This is why, whenever I hear the word “relational,” I reach for …