Re: Joins with nulls

David Cressey wrote:

>
> If the transaction never got committed, nobody else can see any part
> of that
> tuple. It can't be shared.
>
> Try another example.

Hi David:

I think this is a perfect example.

The situation I currently have and want to duplicate is:

The operator fills in part of a paper report. Though random parts of the report may be blank, there is data. The information is retained. I can retrieve and use the data, including the information that data is missing, at any time by reviewing the paper report. When the next operator comes on shift, he takes the previous shift report and puts it into a filing cabinet in chronological order. (this type of transaction committing is possible with an electronic database too.)

The situation you propose:

The operator fills in half a tuple. Because parts of the tuple are missing, the tuple is discarded. The information is lost. (This is also the position taken by Darwen in "The Third Manifesto").

The paper method I currently have has allowed me to determine that some operators leave blanks when they shouldn't 10% of the time and others up to 40% of the time with a median of about 17%.

If I were to adopt your method, this statistic would become one of Deming's "Unknown and Unknowable numbers".

The view that the incompleted tuple must be discarded results in a system that is inferior to pen and paper because it loses information.

JE Received on Wed Nov 27 2002 - 07:53:59 CET