I agree with the idea of "inspiration source" about null values in the database

Personal opinion, for reference only.
When designing a database, null values should never be allowed in the database!

The null value is not allowed in the actual business model because it has no meaning. Currently, the database system provides the null value function, this is one of the functions of the relational database that has passed the mathematical test. Its function is like pointing out a common meaning that "no" or "no", but I think, this is one of the issues that the relational database thinking does not fully constrain.
First, if the database is expressed as an independent data and has a null value column, it can certainly make a correct response to external information, but if the database acts as an interactive interface with the outside world, when there is an independent internal business expression logic, the emergence of null columns should not be allowed, strictly speaking, for external applicationsProgramThe emergence of null columns is not allowed, because this not only requires external applications to evaluate another judgment, but also requires external applications to be able to process similar conditions, obviously, programming complexity is increased.
Secondly, in the object model, a fixed object has n fixed attributes. Generally, based on the combination of all attributes, we can find the specified object, if the attributes of an object change, it does not affect the object, but if the attributes increase or decrease, the class of the object will be changed.
The same is true for the relational ing in the database to the object. In some cases, the null property will be recognized as this property does not exist (although it will suddenly have another property, but this should be the status of the object rather than the object), which is not conducive to the ing between the relationship and the object,
In Java, there are O/R objects and relationships that can be converted ,. although there is no mature tool in net, I think it is still necessary to adopt the OO idea. After all, the description of things is a complicated process, especially for developing large databases, the most practical problem is that business logic rules will seriously affect programming efficiency.

Therefore, the null value problem should be solved by the database design, rather than being processed in the data access layer of the application.

the source of inspiration is correct, and I agree. In addition, in any case, the null value must be solved in the database, because any stored data type should be fixed, common variables in VB6 bring about efficiency and programming logic troubles. I believe that all people who study VB will understand that this is not just a good habit and normative issue, it is more about modeling the real world.