One of the worst databases I have ever seen was a database for a Web site that needed to support the following:
Just considering recipes, what sort of tables might we want for recipes? Possible tables include units of measure, ingredients, recipe categories, recipe author and perhaps difficulty level. Given everything that I've listed, how many tables do you think this database had?
Nope. That's not a typo. This Access database that was driving a Web site had four tables. (The "DBA" that is no longer working with us told the project manager that the database design was fine.) When we bid on the site redesign, they couldn't understand why we wanted to redesign a database that worked for them. Never mind that no recipes were allowed to have more than eight ingredients or that "difficulty level" was an arbitrary string that could be typed in.
This was the worst database I've seen, but frankly, with the exception of large-scale, successful projects, this is the quality of most databases that I see. I hardly claim to be a database guru, but I could run circles around these monkeys -- in my sleep.
So why are so many databases absolutely worthless? I was reading a book on database design and the author -- a college professor -- noted that he was sometimes approached by programmers wanting to teach database design because they knew SQL. While knowledge of SQL and knowledge of database design are not exactly orthogonal to one another, knowing SQL does not mean you know how to design a database, but too many programmers don't understand this.
Personally, I think if you don't have the basics of database normalization down, you have a large gap in your knowledge. Learning normalization will make you a better programmer (and vice versa, I suspect).