Re: On specialization constraints time of application

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:1k3Zl.25790$as4.24845_at_nlpi069.nbdc.sbc.com...
>
> "Walter Mitty" <wamitty_at_verizon.net> wrote in message
> news:fA1Zl.926$P5.503_at_nwrddc02.gnilink.net...
>>
>> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
>> news:SO0Zl.25789$as4.24386_at_nlpi069.nbdc.sbc.com...
>>
>>
>>> It is my opinion that nulls are not inherently flawed, but that it is
>>> the misinterpretation, and the consequent misuse of nulls that are.
>>
>> Agreed.
>>
>> Having said that, my preferred interpretation of NULL is different from
>> yours.
>
> There are a number of interpretations. Raymond Reiter in "A Sound and
> Sometimes Complete Query Evaluation Algorithm for Relational Databases
> with Null Values," Journal of the ACM, April 1986, argues that nulls are
> constants for which there is no unique name axiom. Codd, in his book,
> RMv2, states that nulls are not values, but indicators and distinguishes
> between inapplicable nulls and applicable nulls by using two separate null
> indicators and 4VL. Others argue that there are many different kinds of
> null, but what that boils down to is that that there are many different
> reasons that a value either should have been supplied but hasn't, or is
> not applicable, and that reason should somehow be encoded as the kind of
> null value. The interpretation that I take issue with the most is the one
> that uses the same symbol to indicate both that there can't be a value and
> that there can be a value but it hasn't been supplied.
>
>

Interesting.

In the case of "no value supplied, by reason of inapplicability", I consider the "by reason of inapplicability" qualifier to be metadata, not data. As such, there should be room in the definition (header?) for the proviso that if nulls appears in this context, all these nulls are inapplicable. I note in passing that, when a null is inapplicable, if a value had been supplied, that would have been an error. And, as you and others have pointed out, inapplicable nulls can be removed by decomposition. I can't think of a good reason not to decompose at the logical level. The physical level is another story, maybe.

In the case of "a value should have been supplied, but none was" I think of this as an exception, kinda like the exception that happens when an attempt is made to divide by zero. All the null marker does is convey the exception from the context in which the data was stored to the context in which it is to be used. If there are some queries that are unaffected by the presence of nulls in some places, I'm going to call that a specialized case of data independence, which might be called "data exception independence" or "data absence independence". .

The world of practice is full of people whose professional development consists almost entirely of OOP, and who are suddenly coming up to speed on both SQL and database design. Not only that, but they have a very short deadline to produce deliverables, and an intentionally narrow view of the value of stored data. These people often unconsciously associate meanings with nulls that go way beyond anything that you or the experts you cite would accept as a useful meaning for that symbol. If you ask them, they will revert to the meaning that they attach to a pointer that doesn't point anywhere. In that world, promoting some sort of "best practice" in restricting the use of null tends to fall on deaf ears. Received on Sun Jun 14 2009 - 14:23:54 CEST