Re: 3vl 2vl and NULL

From: Anne & Lynn Wheeler <lynn_at_garlic.com>
Date: Thu, 15 Dec 2005 14:28:13 -0700
Message-ID: <m3ek4edp8y.fsf_at_lhwlinux.garlic.com>


"David Cressey" <dcressey_at_verizon.net> writes:
> It's not commonly accpted. It's commonly accepted that, for every
> database that end up with "missing" values due to inapplicable
> cells, there exists an alternate design that would have expressed
> the same inapplicability by an omitted (not missing) row, rather
> than by an omitted value in an existing row.
>
> What's not commonly accpeted is that the design that contemplates
> inapplicable data is "wrong".

another way of viewing is that there is a state diagram that involves how and/or/etc is implemented across the various state combinations. it doesn't necessary make it right or wrong ... it is just the way it is.

a reference to early posting about '92 data article on the state diagram. it is similar to truth table ... but since it involves states other than truth ... it is possibly more accurate to calle it a state table ... defining the logical operations for the various state combinations (not unlike how one might define logical operations on sets).
http://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?

the sql state table from date's article

and   T   U   F        or    T   U   F       not
-----------------      ----------------      --------
T     T   U   F        T     T   T   T       T     F
U     U   U   F        U     T   U   U       U     U
F     F   F   F        F     F   U   F       F     T

some confusion comes in when people apply connotations to the different state labels and any belief they may have about how their beliefs relate to the different state labels

another possible view is that the implementation defines the states it has implemented and it defines how it implements logic operations on those states.

confusion can be aggrevated when people's connotation beliefs result in a state table other than the one that is actually implemented. this in turn can result in unanticipated results when they are doing appilcations. in traditional programming languages when somebody writes program language statements that produce different results than what they expected ... the programmer is frequently blaimed for not following the language implementation correctly. another approach might be to blaim the language implementation for not being done in a way that corresponds to what the programmer believes to be correct

aka is it a feature of the language as opposed to a bug in the language? ... typically bugs are when things don't operate as specified. features are frequently when things operate as specified ... but possibly not as expected.

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Received on Thu Dec 15 2005 - 22:28:13 CET

Original text of this message