3 ms·

You don't need a pair of columns to replace a nullable column. I was addressing the second part of your comment not your questioning of allowing nulls. Nulls

You don't need a pair of columns to replace a nullable column. I was addressing the second part of your comment not your questioning of allowing nulls. Nulls have their place I believe, but they are grossly overused. For example, if you have a Person table, then something like a nullable DateDied is logical and acceptable over a sub-type solution. But something like HairColor should not be nullable to cater for bald people, it should non-nullable and reference a table that has a 'none' value. On another note, I don't think you can eliminate the null concept because they are the implicit outcome of outer joins and therefore means of comparing and aggregating nulls needs to built in.

derefr 13y ago
> if you have a Person table, then something like a nullable DateDied is logical and acceptable over a sub-type solution. But this is exactly where NULLs are bad. "DateDied IS NULL" could mean many different things, semantically: - This person hasn't died - We don't know if this person has died (the information was not provided with the record when imported) - DateDied is not an applicable property for this subtype of Person (for example, if you have an ImmortalPerson subtype.) There are probably even more, if I wasn't just going off the top of my head. When you do an outer join, you get another level of NULLability--which would perfectly map to another layer of "Nothing | Just something"--but without that, you get those NULLs mixed in with the other three types of NULLs above. And then you insert all those into a table, export it, and import it somewhere else... and nobody knows what any of the NULLs mean.