Fortunately, a large percentage of columns are text types, in which case you have the beauty of the empty string so that you can avoid NULLs in pretty much any text column.

—Theory

Second, the technique benefits from distributed foreign keys, something I’m not aware of any database supporting. I suppose you could write triggers or stored procedures to handle this, but if you wanted them to be performant over large tables, I suspect you’d have to create and manage your own indices. (That being said, I’d kill for distributed FKs in our work app).

So I’d suggest that you never, never use NULLs. Until you have to. Then just use ‘em sparingly.

The problem comes down to what NULLs actually mean, as Ovid says. Technically, the mean “the value is unknown.” This is distinct from, “the value is known, and it’s a non-value.” From a semantic point of view, how your application treats these two interpretations may be the same, in which case you have no problems with NULLs. I find that such is usually the case.

In some situations, however, the distinction becomes important, and then you need to do something about it. The nice thing about an empty string in a text column is that it encompasses the distinction beautifully (an empty string is a known value), while the truthiness is the same (in Perl) for both an empty string and a NULL. I only wish that SQL had a way to represent the distinction in non-text types. But long term, as folks moved toward the sixth normal form, NULLs and their inherent ambiguity will be, in practice, eliminated.

—Theory