Database Rant #1

Why is it that every time I see a database it’s fucked up in some way or another?  Probably I only notice databases when they are screwed up.  Like a well-designed and maintained machine, databases are invisible when they are working well and I don’t have to pay attention to them.  But I keep seeing a lot of damned databases, and (if you couldn’t tell) it doesn’t make me happy.

It seems to be no coincidence that the majority of the (um) “issues” on The Daily WTF involve databases and their mismanagement.  Speak not to me of data being in the wrong normal form or needing more indexing or of foreign key kung-fu.  Sins at these levels appear to be far, far beyond the skills of the everyday database codermonkey.  Most screwed-up-ness is at the level of aggregative complexity, or less technically, “We got here by piling a bunch of new crap on top of a lot of old crap and every Large Engineer we’ve hired to help us out of the mess has made weird signs with their fingers and run away (sometimes screaming).”

I swear to God that Oracle should be renamed Cthulhu, Eater of Data and Consumer of Programmer Souls, but I might be over-reacting; you can commit crimes against humanity in nearly any database code.

Look, people: A database is a responsibility, it is a burden that you are going to suffer as long as the data is important to you.  If you just toss in data and relationships and stir you’re going to wind up with grey muck that looks it wants to eat New York again.  If you stick a lot of stored procedures in there you’re going to have a bunch of stateful shit happening every time you touch something, and that stuff is very nearly undebuggable.  If you shoot yourself in the foot, it hurts.  Stop making systems that hurt you.  Is that so bloody hard, or do you like having your pager go off at O-Dark-thirty with yet another screwed up inner-whatsis-join-procedure bug?

Rule #1 is therefore: Thou shalt not make your schema too fucking complex to understand.

Rule #2 follows quickly: Thou shalt make your database accesses ditto.  Stop spreading them everywhere.  No sneaking updates or queries into a zillion different places in your application.  In other words, actually spend some time to design.

Once upon a time I was working on a database-centric application, an exploratory rewrite of a horror that shall remain (as good horrors should) nameless.  Maybe a month into the design process the marketing drones in this company got wind that we were doing an investigation into replacing the current Deployment Nightmare from Hell, and one of them came up to me and asked, “What database is the new stuff going to use?”

Now, I could have claimed ignorance, but I knew quite well what they were asking, and shivers went down my spine.  They didn’t care what the schema looked like, or what kind of abstractions we were building in order that we wouldn’t accidentally couple to a particular data access engine.  They were asking if we planned to use Oracle or SQL Server.

I accidentally told the truth.  I told the marketing drone, “It doesn’t matter, the new access layers will talk to anything, so we can run on anything” and to their ears this meant “We don’t know what the fuck we’re doing, we don’t even know how to spell the word ‘Database,’ how about that?”  It didn’t matter that they were doing the equivalent of asking someone who was about to embark on a long road trip what brand of gasoline they were going to use.  The marketing folks didn’t understand that database engines are supposed to be a commodity . . . and that projects that targeted to the features of a specific vendor are usually the ones to run into quality problems (which the old product had in double handfuls).

Anyway, the marketeers panicked clear up to the CEO (okay, in a small company this is only a couple doors down the hallway, but still) and I got called on a the carpet a little and had to clarify, “Sure!  We’ll work on Oracle!” and then shut my trap (instead of continuing with “and SQL Server!  And MySQL!  And a Goddamned flat file encoded in Klingon EBCDIC if you have a stupid ODBC driver for it.”)  You’d think that the marketing drones were getting kickbacks for buying copies of Oracle or something.


(There was a $200K piece of software on a shelf in the Dead Computer Room; some kind of enterprisey control sales site management blahdiddity package that this company, a start-up, had bought and that the shrink-wrap had never come off of.  What a waste).

Rule #0 remains: Stop hurting yourself with bad decisions.  No, really, just stop right there, take your fingers away from the mouse and keyboard, maybe even shut down your workstation for a couple of hours.  Sit there and think.  Doodle on some paper.  If someone comes by and wonders what you’re doing, mumble something about Bayes-Yegga threat analysis or something.  Your time spent staring at a blank screen will be well-rewarded (at least your fingers won’t be doing any actual damage…).

Author: landon

My mom thinks I'm in high tech.

2 thoughts on “Database Rant #1”

  1. Forlornly, I .. once upon a time … had to select/update/join ‘data’ in the neerland known as the eBay schema(s).

    I shall never be the same.

Leave a Reply

Your email address will not be published. Required fields are marked *