In the first design, the meaning of the "data" column depends on a non-key column. This would then appear to be a violation of 3NF. The data column has a dependency on the type column, and "type" is not even part of the primary key.
This makes it a lot more work to ensure the integrity of the data. What is there to prevent you from changing the value of the type column in a way that makes the data column meaningless?
Your description of the columns makes it clear that the scheme proposed by Anonymous Monk in Re: OT: benefits of database normalization as "design 3" more accurately captures the data model. In that model, the data type on the column will (in most DMBSs) suffice to keep the data mostly right, with simple referential integrity constraints covering the rest of the bases.
In reply to Re: OT: benefits of database normalization
by herveus
in thread OT: benefits of database normalization
by revdiablo
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |