Re: Do we really need NULL??

Martyn=Jones%Suppliers%HQIM=Mun_at_bangate.compaq.com writes:

>Hi,
 

>Maybe I've got the wrong end of the thread regarding NULL, however,
>I belive that NULL is used to represent NOTHING, NULL should not
>imply MISSING or UNKNOWN or NOT-APPLICABLE directly.
 

>I would suggest that you use an attribute facet so that you can
>identify why a particular attribute has been designated NULL.
 

>On the other hand you can insert your NULL extensions directly into
>attributes, for example
 

> N/A for Not applicable
> U/R for Unreadable
> V/M for Missing value

>Martyn Jones
>Compaq Information Management HQ
>Munich, Germany

We store the "NULL extensions" directly into the attributes (but this means all fields must be CHAR). These are decoded to NULL in the views defined on top of the tables (where the CHAR values are also decoded to their appropriate actual datatype). A separate table stores details of why certain values are bad or indifferent, and what is being done about it.

Our tables tend to have many columns - we collect alot of medical variables for each person - and having a distinct attribute accompanying each column, to indicate why it is missing would cause practical problems, with excessively large tables. The dependence between the value and its accompanying "status" attribute would be difficult to maintain.

The ideal solution would be the ability to define new datatypes other than CHAR, NUMBER etc. I'm not exactly sure what an "object oeriented" database is, but I'm pretty sure from some recent reading that the ability to define new data-types is, or will be, one of the characteristics of these beasts, just as it is a characteristic of OO languages, like C++. E.G. we would want to define a datatype that contained within itself an indication of its own status.

alan

     __
    (_at_@)
  / \O \
  m( ) ( )m                    Received on Wed Nov 16 1994 - 04:11:58 CET