Normalization is the process of removing repeating values from your data design, and ensuring that the values depend on the Primary Key in the table. OK, it’s a bit more complicated than that, but this definition will do for this post.
So how far DO you normalize? Consider the following:
Name, Address, City, State, Zip.
You might normalize it to the following:
FirstName, MiddleName, LastName, AddressLine1, AddressLine2, CityOrMunicipality, StateOrProvidence, PostalCode.
That seems pretty well normalized, and ready for a Primary Key. But let’s drill in a bit – the StateOrProvidence column is going to repeat, here in the U.S., quite a bit. Perhaps a Foreign Key is needed there, and another table created with WA, FL, GA, etc?
You could do that. But in most cases you’re too normalized if you take that route. In the case of two-letter state names, you’re not saving much space and there are other ways to enforce the data integrity of that column.
You must consider the reason you’re normalizing the table, and ensure your design fits that requirement. In most cases, it’s enough to tell the developers to code a drop-down list of the acceptable values, and/or put a constraint on the column to enforce what you want.
So apparently you can be too normal(ized). At least in this DBA’s experience.