Let’s face it, none of Information Technology is easy. Oh yeah, there are those few geniuses that have an absolute grasp over some small aspect of the stack, or those other geniuses that have a very shallow knowledge level, but understand the entire stack. But the stack itself, it’s vast, deep, wide, utterly unfathomable. So what do you do? You cheat. You take shortcuts. You ignore things you don’t like/understand/appreciate. And then there’s all the things you just don’t know. Or, you cheat another way, you get experts that have drilled down on a particular technology so that they’ll provide you with the knowledge you need. Ah, but then you have to listen to them and what happens when your local genius (deep or wide) doesn’t agree with your hired gun? Do you override your local person for the hired gun (I’ve seen this happen a ton where consultants were favored over in-house), or do you go with your local person (I’ve also seen this where the local person who has solved all the problems before may be over their heads now, but they’ve always been right and are therefore trusted)?

I just read (and I mean I finished about 90 seconds ago) this really interesting article on The Curse of the Excluded Middle. I won’t even pretend to you that I understood all of it. But, I did get a pretty fundamental concept out of it, this programming stuff is very hard, we’re going to take shortcuts to get through it, and those shortcuts come with a cost. The argument being put forward isn’t to somehow find a magic solution. It’s simply to acknowledge that there really is a cost, maybe even a cost you don’t completely understand. Further, that cost, and especially your lack of understanding of it, will come up and bite you on the behind.

Which brings me around finally to developers and databases. Relational databases are a pain the bottom. They really are. Speaking just of SQL Server (where I spend most of my time) you have to work with a ridiculous, archaic, language, T-SQL, in order to manipulate the data. And the rules of normalization, yeah, we can all learn them, but applying them makes every single aspect of coding harder. Plus the language lets us do things that it then interprets in horrendous fashion. Oh, and don’t forget all the obscure and weird maintenance and configurations that you have to go through to keep the silly servers online and functioning correctly. Then there’s the whole object/relational impedance mismatch thing to chew on our behinds even further. In short, I completely understand why developers would like to burn the entire edifice to the ground (come see one of my presentations when I talk about the “data persistence layer” that a particular dev team wanted to build). And all that is just the technical side of this mess. I’m not even going to address the personnel issues that come with the different focuses of responsibility between a developer and a DBA.

So when the developers bring in an Object Relational Mapping (ORM) tool or they explicitly attempt to slap out at DBAs by going after a NosQL database (and no, despite the new twist, it means NO F’ING ESSQUEELL, instead of Not Only SQL as many are saying now), I understand why they would do this. It short circuits all the issues. We get around the problem. We speed development by eliminating that thing that we didn’t completely understand and certainly didn’t like and…. Hang on… Isn’t there a darn good chance we’re digging a hole here?

Yes.

Don’t get me wrong. I see the need for unstructured data stores, ID/Value pairs, speed over consistency, speed over durability, the need to move fast because your competition is sure as heck trying to move fast. So NoSQL databases serve an absolutely valuable purpose and used correctly fix unique and difficult problems. A well structured ORM properly applied absolutely saves development time. But there’s this nasty little surprise hidden behind the need, the sometimes seemingly desperate need, to completely get rid of relational storage. That surprise? Relational storage actually works and works well when applied to the appropriate problems in the appropriate ways. It provides a means of collecting information fairly quickly (although not as fast as many NoSQL databases), storing it efficiently (although, maybe not as efficient as some object databases), and returning it to the users on demand (and here relational does stick out again). And does it all in on place, not one for collection, another for reporting, or some of the other strange perambulations I’ve seen people going through with some NoSQL implementations (again, not all, some are awesome, but many are horrific).

About twice a year I get to read a “death of the DBA” article that points to a technology or process or tool that’s going to eliminate the need for those nasty, ugly, difficult, relational databases and those freaks who try to keep them online and available. And about twice a year I see lists of the most needed workers in IT and guess what’s almost always there, yep DBAs. The fact is, relational storage does work. And instead of trying to eliminate it, or the DBA, or the code necessary to interface with it, embrace the stuff and learn to use it, or hire someone who actually knows how to use it and then listen to them. I’ve just seen too many places where the need to eliminate relational storage and DBAs is driven by one of two things, I have a shiny new hammer and everything is a nail, or, databases and DBAs are a pain because they make us do stuff we don’t want to, so let’s bypass them. Those are almost precisely the wrong reasons to go about moving to a NoSQL implementation, because you’re going to be ignoring stuff, as the Curse of the Excluded Middle talks about (and I know, it didn’t talk about databases, I’m extrapolating, hang with me here), and the things you ignore, or worse yet, don’t know about, are going to hurt and may hurt badly.

The post The Curse of Relational Databases appeared first on Home Of The Scary DBA.