Friday, July 22, 2005

Pointless geeky ranting

So I submitted my very first database change order the other day. What exactly is a database change order, you ask? Well, when programmers are creating an application, they generally have a database they are using. And they end up needing to create new tables and fields in that database to accomodate the application they're building. Such is the case with the project that I'm working on.

Now, as I've mentioned before, up until a couple of weeks ago, there was another programmer helping me with this project. And since he has way more experience than I do with SQL, he's been the one creating most of the tables, fields, etc. for our project in the database. He knows most of the database naming standards that we have to follow here. (Standards = rules on how we have to name tables and fields and stuff in the database) And he's kept a pretty good list of all the changes he's made.

Here's the kicker. All of the changes he's made are to the DEV (development) database. This is fine while we're developing the application, but eventually all of these changes need to be incorporated into the QA (quality assurance) and PROD (production) databases as well. These are the more "official" databases that will eventually be used with our application. DEV is just for us to use while the application's in development. And here's where that database change order comes in.

A database change order is a form I have to fill out that lists all the changes that I want incorporated into QA and PROD from DEV. So I filled one out and sent it in to our database modeler the other day. Keep in mind that almost all of these changes are ones that the programmer that is now gone had made, not me. And while I use some of them for the screens that I'm working on, so I know what they do... others I have no clue. I just know that they (usually) work.

So yesterday I get my change order back again from the modeler, basically wanting a lot more explanation for some of the fields/tables and what they're for. Ok, that's fine. So I fill in better descriptions of them. Then today I get the change order back AGAIN. This time since she has descriptions now... she lets me know what doesn't follow the standards. Here's an example:

We have a phase here called "Requirements Definition". We NEVER call it that. It's simply "RD". Which is why I have a field called RD_MS_DT - RD Milestone Date. Apparently MS is too short, so it must be MLST. Fine, whatever. But she wants to change the field to RQMT_DEF_MLST_DT. *sigh* A little bit irritating, since we always just call it RD. Some of the other fields like that I had to even go back and look up what the acronym stood for, because I didn't remember.

And then there's the field that she wants to take out of one of the tables completely. I can't wait to see what that will break...

As one coworker put it: "database design by those that won't even use it. Isn't it grand?" Oh, and have I mentioned that I hate having to fix what other people created that's broken?

Ok, end of rant. And yes, I realize that this entire post just made me look like a huge nerd and it's probably way more than you EVER wanted to know about my job. But it's my blog, my outlet. Deal with it.

2 Comments:

BurnDark said...

Not that I mind you posting anything geeky, but you may want to be cautious about doing so, as it may violate your NDA. What you are posting is highly generic, but it is better to err on the side of not giving away too much.

1:05 AM  
Sheryl said...

Yeah. I would never post about anything detailed. My company is very government regulated due to the business that they're in.

9:36 AM  

Post a Comment

<< Home