>>>That depends on what you mean by "natural", John.
>In some cases, a char field, for example, that allows NULL's functions quite differently from a char field that doesn't. I consider that unnatural.
>
>Char is less problematic because you can have a blank value. But absence of value may not mean the same as blank. Not an issue if the developer does it on purpose and plans for it IMHO.
>
>>>You have a point with dates, but SQL Server pre-empted that by setting blank dates to an arbitrary value, so that scotches that idea.
>
>When that first happened, 12/30/1899 was still a valid date of birth for living people. Still is for parents, dates of construction of buildings, events, contract dates... I guess if you know for sure you'll never ever need any of that, you could rely on a placeholder and remember to exclude it every time when doing date range queries. Or you could use NULL.
>
>I'd also raise the issue of the year 1753. There are plenty of reasons to want dates before 1753, meaning you can't use SQL Server. Perhaps the sorts of people likely to want open date ranges and NULLs have already abandoned the MS camp, or should.

"Magic numbers" are poison. I don't want them anywhere near my code.