I need to run to work soon, so this will be brief.
I've only been with the company for a couple weeks. It is a good company, this is a contractor who just happens to be twice my age. I am new to the professional programming field.
This database does exactly what wikipedia says not to do for 1NF. It repeats telephone columns in various tables. That is one strike.
Strike two: Some data is duplicated across tables. Flat out duplicated.
Strike three: Not vital, but he turned all the keys into bigints. All the "FK_" are also nullable. Wtf?
We have not started using this database YET, but there has been a big time crunch to meet the client's needs and timeline since I joined and the current timeline will put it into use, say, tomorrow.
It was okay for me to sit back while he made a mess since I did not have deal with it directly, but it sounds like I'm going to be taking over this section of the code while he's needed to architecture something else.
Any advice would be greatly appreciated. My boss is a great man, but is also very, very busy and more stress is the last thing he needs.
Sorry this came off as a rant and less of a proper question. I really do appreciate all of the responses and they've helped me start viewing the "problem" more analytically. There's also some benefit to them being generalized in that the same advice will still apply to future "problems."
So I kindly tried to figure out why he did what he did and for the most part he even admitted he didn't have a very good reason. We ended up spending some time and cutting almost all of the duplicated columns. For the rest of the oddities, I can bite my cheek well enough since they're just annoying and won't potentially wreak havoc if every duplicated field isn't updated. All in all a good day.
PS I'm having a hard time choosing a best answer since there are so many good ones.
Update: October 2015 Just for fun since it's great seeing what I wrote four years ago... I'm leaving the rest unchanged to preserve its youthful qualities :)
The senior guy in question was fired within a couple months and we ended up re-writing the product from scratch keeping almost nothing of the guy's code or database. Him being "needed elsewhere" was the start of that transition. (Sometimes you're right...)
Answers and advice given here are still really good: Learn why somebody else did something before you criticize. (... and sometimes you're not.)