Why don't you impose NOT NULL constraints on flag items?

Developers' experience has shown that it is more beneficial to impose NOT NULL constraints on items that do not require NULL.

Your question is similar to SQL Anti-pattern, which is called Fear of the Unknown

(I don't have any data, so I remember it vaguely.)However, in Fear of the Announ, NULL would have mentioned anti-patterns that put NOT NULL constraints on items that require NULL.
For example, when unentered = unknown is set in the column male=1female=2, an "unknown" is added to the input field one day to make unknownunentered=null.

Another anti-pattern is that columns that require NOT NULL constraints are not constrained.
When searching for a record that is not flagged valid, if NULL and '0' are mixed, some anti-patterns cannot get the correct result in ENABLE_FLG NOT in('1').

I remember that the conclusion of the above document was to understand the characteristics of NULL and use it appropriately, and to avoid anti-patterns with NOT NULL constraints if necessary.

As for the disadvantages of imposing NOT NULL constraints, some people may argue that the operation such as insert is a little slow.
According to the verification article, Oracle will slow down approximately 0.6 percent if you insert 1 million data.
The speed difference is negligible in real-world operations.

• NOT NULL Unrestricted - 172.411 seconds
• NOT NULL constrained - 173.474 seconds

The main reasons for designing flag items not to impose NOT NULL constraints are as follows:

• Inserting with a common function in the framework will always register the flag, so the constraint will only slow down
• All you have to do is search by ENABLE_FLG='1', so anything else is fine.
  • The idea that normal processing doesn't search for logical deletion, so it won't cause an accident
• When creating test data, I want to eliminate restrictions because they are a hindrance.
  • There is also a scary tester who updates the deletion flag to null when logical deletion of test data...
• Simply forgetting/restricting? What's good about that?

• The idea that normal processing doesn't search for logical deletion, so it won't cause an accident

• There is also a scary tester who updates the deletion flag to null when logical deletion of test data...

In any case, not imposing the necessary constraints is similar to the state in which the intent of the table design is not reflected in the substance of the table, and the composer does not write strong or weak symbols such as Forte Piano on the sheet music.
Wouldn't it be healthier to have an environment in which developers and performers can't do anything unfair due to restrictions than to have an environment in which they interpret freely?

*We can't prevent the tragedy of newcomers and infrastructure teams saying, "I'm not sure, so I removed the restrictions!" but we will not include it in our answers because it's about sharing information and the system.