Database normalization is still an important skill, and may even be applied to object design as well. One of the first rules of normalization is that all the attributes in a table must be dependent on, and only on, the primary key.
This means that you cannot have a column in a table that changes meaning based on the value of another column which is not the primary key of a table. I’m surprised how often this first rule of normalization is violated, and the havoc it causes when working with a database implementing it.
For example, you have a table with the data columns Name, Source, and a primary key ID. In this implementation we don’t know what name represents. The meaning of the column name is dependent on the column source. This technique is sometimes used in EAV database designs (Entity Value Relationships) where we define the database structure with our own tables and their content, rather than the database table design and relationships. However, an EAV would include both ID and Source as the composite primary key.
What exacerbates this kind of design flaw further is when there is no table defining the contents of the column Source. So, now you have to columns in a table that must be used together to get a clear understanding of what the contents of the Name column represents. Name could be a Part Description, the name of a Person, etc. There is no control over what the data domain of the column Name may contain.
This flaw makes your code hard to write and maintain. It also results in corrupt or unclear data. Stay away from this newbie design. If you aren’t sure what this is all about, its time to take a trip down the learning path of database normalization. A google search returns a number of resource if you search for "Database Normalization". If you are an application coder, rather than a database developer, you may benefit from this exercise as well in that it helps lead to better object oriented designs.
Cheers,
Ben