I agree that null is a bad idea, because it introduces ThreeValuedLogic into the database, which makes things very confusing. Example:

        Prod-ID Product        Cancellation Date
        ----------------------------------------
        1234    Fooz Ball      (not canceled yet)
        2345    Teeth Cleaner     12/01/2008


In most databases I have seen, null is used to represent the '''not canceled yet''' idea. My proposal here is based on the idea that using null for that is wrong,
after all, when we do queries against this relation (or table if you prefer Sql nomenclature), we are going to want to ask questions like:

CancellationDate is equal to  12/01/2008

or

CancellationDate is greater than 12/02/2008

and we are going to want to have definitive "true" or "false" answers for those questions. But there will also be cases when the Product does not have a cancellation date. For the purposes of the system, it is irrelevent if it will ever have one, the fact is that right now it has none. So, why not add a "none" to the Date domain? that way questions like:

CancellationDate is none

Can be answered, with a definitive "true" or "false". No need for three valued logic here!

And in case of questions like:

CancellationDate (lets say it is 12/02/2008) is greater than Date (lets say it is none)

Well, the answer would be "false". Again, no need for three valued logic.

This would make it possible to avoid the confusing issues of ThreeValuedLogic while at the same time avoid awkward normalization tricks to avoid having empty values in tuples.

What do you think? Should none be a standard feature of Types/Domains in RelProject?

''It is trivial to define for user-defined types.  E.g:''

 TYPE Date UNION;
 TYPE D''''''ateValid IS {Date POSSREP {year INTEGER, month INTEGER, day INTEGER}};
 TYPE D''''''ateNone IS {Date POSSREP {}};
 TYPE D''''''ateUnknown IS {Date POSSREP {}};
 TYPE D''''''ateUserRefusedToAnswer IS {Date POSSREP {reason CHAR}}; 
''Appropriate semantics are defined in operators for the Date type, which are not shown here because they can be whatever you like.  They are yours to define.  Unlike most object oriented languages, TutorialDee uses MultipleDispatch so operators are not bundled into the type definitions.''

-----

'''None and Strings'''

Some might feel that adding "none" support for Date is something unprecedented in Databases, but it is not, Strings have always had a way to represent "None" without using "Null": The Empty String.
All I am asking here is to have the same support for other types (such as Date, Numerics, etc). 

----

O maybe I should have named it AddingNoneForDomainsInRel ? --LuxSpes

----

See also RelProject, TutorialDee, NullVersusNone