Re: The BOOLEAN data type
Date: 18 Apr 2003 08:15:26 -0700
Message-ID: <61c84197.0304180715.23ded92b_at_posting.google.com>
Costin Cozianu <c_cozianu_at_hotmail.com> wrote in message news:<b7ncgr$2odsj$1_at_ID-152540.news.dfncis.de>...
> --CELKO-- wrote:
[large snip]
> What happened to that requirement ?
>
> Besides, three valued logic is totally unnecessary. You know the saying
> instead of feeding the hungry give him a fishing pole and teach him how
> to fish.
>
> If you support sum types (see the parallel thread), I don't need three
> valued logic, classic logic is enough.
Not sure I agree here.
>
> Using a decent type system , I can define a three valued logic boolean,
> in 5 lines of code and reuse it all over the place where I need. If I
> really need to I can dfine a fuzzy boolean data type in a hadnful of
> code and reuse it all over the place.
Yes - not that difficult.
>
The to me fundamental problem is how to cope with missing values. I
agree that You have no need for them in base tables, but what happens
in the situation where you have an outer join? If outer joins are to
be provided by the DBMS - and I believe they are to useful to be let
out - there must be some means of denoting that a field has no value.
There are three ways to go:
what value should we store in that field? If we have ADT's we must be
careful as the ADT might have some constraints, that if not set will
invalidate the type - a CIRCLE could as an example be required a
non-negative radius. Even non-ADT types might have some integrity
constraints: think about a floating point number stored in the IEEE
format.
My personal conclusion is that we are stuck with NULLS - if not in the SQL sense then at least in the sense that we are to have some kind of sum type. And if we are stuck with such a type, then the only sensible thing is to have it standardised by the DBMS - how else are we going to let the DBMS perform the outer join by itself? This is getting very off topic, however, so I have started a new thread on this subject.
Kind regards
Peter
Received on Fri Apr 18 2003 - 17:15:26 CEST