Database Administrators (especially Oracle) are the least appreciated members of the IT Community. Sure, it may seem like it's easy work. After all, how hard could it be to ignore the first three requests for help, reject the next two on grounds that the request form had clerical errors, make up a technical rejection reason (“partial index hash scan may cause the secondary file store to incorrectly lock“) for the next, and then, after another few days, finally fulfill the request?

It's not easy at all, especially making up technical reasons: there's only a finite number of database terms that will fly over the average developer's head! So with this in mind, here are two stories that I truly hope will inspire you to give you DBA a big hug.

The first is from Mikey, who apparently id survived that poprocks and soda incident:

I've long ago lost the code, more's the pity. I was reviewing DB interface code in C++ and found that every time we wrote a double into the database, the DBA had converted our double into a string and then written the string to a NUMERIC column type using built-in conversion (this was Sybase, btw).

I asked him why, and he informed me that there was a well-known issue with Sybase handling of floating point numbers. I expressed a certain skepticism of the idea that one of the biggest database systems out there had a problem with floating point numbers. Seemed to me that would be a bit of a major entry in the DMP for a database release...

He insisted, and explained that there were 'some patterns' of IEEE floating point that weren't converted properly when they were stored. The fact that writing from IEEE floating point variables to an IEEE floating point column of the same size doesn't involve any conversion was irrelevant.

So, OK. I wrote him up a little code that would cycle through every possible 64 bit pattern, cast is as double, write it to the database, read it back, convert to a bit pattern and compare the original and new patterns for discrepancies. Aside from shouting if the patterns mismatched, it also reported progress every million patterns.

Based on the log, it looked like we'd have to wait a few years for the final result. When I offered to create a multi-threaded version to speed up the checks, he agreed that perhaps we could just go ahead and try storing floating point numbers directly in the database.

And now here's a conversation held between a certain DBA and an anonymous developer after finally getting the request for a new tableset and related procedures fulfilled:

DBA:  Do you want usernames to be unique?
Developer:  Yes

(next day)

DBA: Should passwords be unique as well?
Developer:  No

(later that day)

DBA: Shouldn't we require passwords to be unique?
Developer: No
DBA:  Are you sure?
Developer: <15 minutes of explanation as to why different users are not required to have different passwords, just usernames>

(next day)

DBA:  Your procedure doesn't return a specific error message.
Developer:  It's a security issue, and should only return "Invalid Username/Password Combo."
DBA:  So if they get the username wrong, but the password correct you're not going to display a specific message?

And for the DBAs out there reading this, take no offense. Just about every other day here is Programmer Appreciation day.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!