There are many discussions about NULL in database design, and my personal design practice is to not use null values.
All the tables I have designed are not NULL fields, especially when I do the table design of the data Warehouse primarily. When I first started using the database, I planted it once. A group inside, I want to show how many adults, another place to show how many minors, a third place to show the total number of people.
N1 (number of adults) = SELECT COUNT (*) from MyGroup where age>=18; The result is 10.
N2 (minor) = select count (*) from Mygorup where age< 18; The result is 12.
To the third place, in order to reduce the query, I directly showed 10+12 = 22 people. Then the customer said wrong, we have 23 people, think for a long time to understand how, and then I often take this test others.
Null is inconvenient to use. Such expressions are supported in various programming languages if (X==null) {...}. But in database theory, NULL compares "strange" logic.
3 > NULL, returns false;
3 < NULL, returns false;
3 = NULL, return FALSE.
To match the null value mechanism of the database, C # introduces the nullable mechanism, such as: int? v1 = Field ("Age"). Value; Otherwise, if the value of age is null, you cannot assign a value to V1.
Null value discussion for database