Soreness and poor database design
The last couple of days have been pretty good. I’m still a little sore from the wreck but thankful that I got out with just a few bruises. I spoke with the other guy’s insurance company today and they hope to get me a check by the end of the week. The claims adjuster was very friendly but I’ll stay skeptical until the check clears.
Work was hectic today. A server at one of the elementary schools went down and we had to get it going ASAP. One of the files used with the Active Directory service had become corrupted due to an abrupt power outage. The initial fixes from MS, tried out by another tech, didn’t work. I knew he was getting frustrated with it so I went out with him to look at it. The first thing I did was run checkdisk on the boot drive (C:) with the repair flag (chkdsk C: /r). That fixed some file corruption and made it so that the other steps MS was giving us worked. The server was back online after about 4 hours. It would have been a lot faster if the server wasn’t as old as it is. Thankfully, it’s being replaced with a brand new Dell server (hopefully soon).
All hail the power of checkdisk.
Today was my first full day in my new position at work. The database is a complete disaster. The person that setup the database has everything (grades, test scores, student names, etc.) dumping into a single table. The table is huge! There is no normalization at all. Plus, to top it off, the previous person left no documentation what-so-ever on how they imported data or how they ran reports against the database.
I’m going to talk to my boss tomorrow morning about the database. I’m going to need a few weeks to normalize it. This, for those that don’t do database work, means I am going to split the one massive table into smaller, more manageable tables that can actually be indexed and are relational with little or no redundant data. With the tables smaller, and indexed, queries will execute much faster. It will be hard because we are talking about a little over 2 years worth of data that will have to be moved around. Of course, this will all be done on a test database, not the live database.
I am also going to need a good week to figure out how to get the new data, sent by the state, into the table correctly. That part would be easier if the database was normalized because the test scores would go into their own tables. That’s where step one (above) will help out.
All of this will take a little time but it will be well worth it. I will also be sure everything is documented.
Speaking of documentation, this quote sums it up quite well:
You can leave a response, or trackback from your own site.






















