Thanks for the comment!

I don’t think learning that being careful with division (or being careful with NULL-able columns) is so far beyond the pale that either should be removed.

Where I would agree with you is a strong statement that columns should not be NULL-able as a general rule and only if there is a specific and articulated meaning for the NULL value.

Thanks for the comment. This example has to do with the documentation for Microsoft not matching what is in the product. I believe the confusion is that someone on the product team at Microsoft used an empty string when I believe they should have allowed it to be NULL.

Thanks for the comment and the feedback. I wrote the triggers post a long time ago, and I doubt I would write that post with the same voice today. This post is more recent and is part of an ongoing debate I have with others on when and how NULLs are used (or misused).

Here for the same reason. Empty string in particular is an important value, and it should be hammered into everyone’s skull that it is indeed not NULL. Strings over an alphabet being a well ordered set, ” is to strings what 0 is to non-negative numbers, it’s the identity element for string concat, yadda yadda yadda.

This example against NULL has nothing to do with NULL.
In this case, coalesce(rtrim(m.mirroring_state_desc),”) not in (”,’SYNCHRONIZED’) and move along.