Corporate: Rant: Stupid DBA rules

Journal Chacham's Journal: Corporate: Rant: Stupid DBA rules 2

Journal by Chacham on Sunday October 17, 2004 @11:12AM

There's so much i could write about a corporation right now. Being i have what to do with them, it's an experience, and the corporate atmosphere is a new thing to me. So much goes on. Thus, i start a new heading "Corporate", because "Corporate Chronicles" is simply too long.

Today's entry is a simple rant. Those moronic DBA's and their ridiculous rules. No, i mean it. I am a DBA myself, but now i am a coder. I don't care much about the schema, that was designed before me, and wrought with mistakes. What i care about are the rules.

The corporation is moving along. For example, that are getting ready for the XP rollout because Win2k is about to go off support. Go fig. And now, they're moving databases (in my case, Sybase) to IBM DB2 UDB.

Here are some of the rules:

Names must follow a list of standard abbreviations.
No SEQUENCEs or "IDENTITY" COLUMNs allowed
No numeric PRIMARY KEYs allowed, unless the data demands it.
No NULLs
Changes to the test database must go through approval

Or at least that's what i've hit so far.

- Names must follow a list of standard abbreviations.

All TABLES start with a specified letter and end with a standard multi-character ending. Now (new system), the limit is eighteen characters on names, and the ending was dropped, but abbreviations must be used. Want to say full words? That's a no-no, most probably vowels or the like will be removed. Underscores are sometimes found. I've got TABLEs with names that can be read in more than one way, or that cannot eb read without knwoing what its for. Amazing eh? And the abbreviations change sometimes. The schema i'm in is inconsistent with itself.

All objects have a naming scheme and COLUMNs have a notation too, and a letter must proceed any COLUMN that is either the PRIMARY KEY or an INTEGER. What is the point of that? If you don't know the data type, you shouldn't be touching the TABLE. However, even if the letter supossedly helps, it doesn't. 'Cus it may be character and a PRIMARY KEY, and not an INTEGER.

They say it's the UDB standard. I say someone needs to introduce them to a baseball bat.

- No SEQUENCEs or "IDENTITY" COLUMNs allowed

I agree with the ban on IDENTITY COLUMNS, they are evil, and belong in something like MySQL rather than a database. Plus, they are unreliable and remind me of Mictrosoft.

But, no SEQUENCES either. Yeah, that standard staple of PRIMARY KEYs is disallowed.

- No numeric PRIMARY KEYs allowed, unless the data demands it.

Want a PRIMARY KEY? Too bad. Your data must define it on its own, unless you have a compelling reason to do otherwise. So, our schema, has a composite PRIMARY KEY in most cases. and it compounds as it goes down. If A is the lookup with B pointing to it, and C pointing to B. A has one COLUMN in its PRIMARY KEY, B has two, and C has three. And I have a hash table with an eleven-COLUMN composite PRIMARY KEY. Just to get to the two hashed. At this point, i want to keep it around. Just so i can laugh at their stupidity.

- No NULLs

This is untenable. No NULLs allowed. What sort of database doesn't allow NULLs? NULL mean that data is unknown. We has thousands upon thousands of data like that. No more though.

So, what do we do? Well, we know are going to add a dummy row to all lookups of spaces (should be zero-length string, but did i mention the no VARCHAR rule too?) to take the place of NULLs. Since we can't have NULLs at a databse level, we're implementing it at the application level. I can hardly believe it.

I asked the DBAs about the no NULL rule, their response was that they were able to avoid problems in the past with it. Sheesh, why not remove computers from the office, that'll solve *all* their problems.

- Changes to the test database must go through approval

No test environment to crash and burn. The test is now treated like a non-critical production server. *Sniff*, excuse me while i cry.

All in all, those DBAs are morons. I'd rather use SQL Server than deal with those rules. Alas, i am not an employee there.

This discussion has been archived. No new comments can be posted.