| >But only variants can be null or empty... That's true, only Variants can be Null (Null is a state of Variant); however, Empty is translated to whatever default value makes sense for some of the (non-Object, non-user-defined) data types: Dim s As String, d As Date, x As Single, y As Double, i As Integer
s = Empty: d = Empty: x = Empty: y = Empty: i = Empty
Debug.Print s, d, x, y, i
(The above compiles and runs, and - no surprise - numerics are made zero, and string made "".)>I'm sure someone has complained about Oracle's idea that empty strings are null values. I have certainly complained about that: I mean, what's not to love about conflating "this field intentionally left blank" with "no certain value could be obtained for this field"? /s >...a rant about how nulls are a terrible offense against the true relational model... By way of Wikipedia, found this: https://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-pri.... A fine read. I am left wondering about how OUTER JOINs would be handled without NULLs. I am now also wondering if it was OUTER JOINs that made NULLs seem necessary. |
Well, probably because Oracle was the first database I used a lot, it just seems natural to me and Microsoft's distinction between the empty string and null is annoying.
On the other hand, if I were to try to rationally defend Oracle's way of doing it, it would be something along these lines:
You can subdivide the concept of "this field doesn't have a normal value" into an infinite number of reasons. So if you're not going to have zero "null-like" options, and you're not going to have one, then where does it stop? When you have two, or three, or four, etc. that seems like you've gone down the wrong path no matter how good your intentions are. It vaguely reminds me of the "zero, one, infinity" rule.