Tower of Power

Too sweet to be sour.

Database Normalization and Design: A Primer

I am by no means a database expert, such titles are best left to people like Peter Zaitsev and Vadim Tkachenko, however one of my co workers has been asking me for some help on how I come about my database designs, particularly issues concerning normal form.

Whlie I could spend several posts going over the intricacies of 1st, 2nd, 3rd, and 4th normal form as well as “The key, the whole key, and nothing but the key so help me Codd” Boyce-Codd normal form, however reality dictates that time spent strictly to these academic levels is either time wasted (projects with due dates unfortunately cannot spend forever on the database design) or pointless as being reasonably intelligent will bring you very close, if not within 3rd normal form.

If you’re really interested, Wikipedia provides a great resource to get started learning the more academic aspects.

I’m going to assume that you have done a bit of database work and at least understand the concept of a join).

The one of the goals of database normalization is to reduce the repetition of information and thereby reduce the complexity of an update of said information. If the same string is in the database N times, we should abstract it so that if we need to update said string due to a typo or anything else, we need to only change but one location.