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/2008In 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 DateValid IS {Date POSSREP {year INTEGER, month INTEGER, day INTEGER}}; TYPE DateNone IS {Date POSSREP {}}; TYPE DateUnknown IS {Date POSSREP {}}; TYPE DateUserRefusedToAnswer 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