Example: an Employee table with an optional DateOfBirth field can be normalized into two tables, one exclusively to hold the DateOfBirth field for employees with known dates of birth. But this adds no semantic meaning to the lack of a row in the DateOfBirth table, and when you query employees, you will almost certainly need to outer join those missing rows back into nulls.
Example: an Employee table with an optional DateOfBirth field can be normalized into two
Share
You are talking about two completely different concepts here. One has to do with Normalization, and one has to do with query results. Having large numbers of nulls in query results is perfectly acceptable, and often desirable, to represent missing values. Having a large number of null values in a table column represents a design problem. Normally, if you find a table that contains a column with large numbers of null values, the table is denormalized. This might be ok for a reporting database, or a warehouse type database. However, for production data, you generally want to avoid this.