The BOOLEAN data type
Troels Arvin
It strikes me as odd that the BOOLEAN data type is not a core requirement
in SQL:1999 while so many other esoteric features are.
Am I right in that it looks like SQL:200n will keep BOOLEAN out of the
core?
I personally find boolean data types useful in many situations. What do
the SQL standards-people dislike about the BOOLEAN type?
Anyways:
_When_ it's implemented, it's not clear to me which domain the type has.
Are all the following values allowed?:
true
false
unknown
null
Does null equal unknown?
/Troels
Tony
> It strikes me as odd that the BOOLEAN data type is not a core requirement
> in SQL:1999 while so many other esoteric features are.
I agree. I've never known a database that didn't want BOOLEAN
columns, but instead had to use CHAR(1) columns with names like
ACTIVE_YN and (hopefully) a check constraint to ensure only 'Y' or 'N'
got stored in it.
> Anyways:
> _When_ it's implemented, it's not clear to me which domain the type has.
> Are all the following values allowed?:
>
> true
> false
> unknown
> null
>
> Does null equal unknown?
null means unknown, so there is no need for a separate "unknown"
value.
byrmol
Troels
It is indeed a terrible ommision considering that Codd stated that the
only data type that MUST be in a RDBMS is a BOOLEAN.
There are only 2 values in a BOOLEAN.. TRUE or FALSE. This is
2-valued logic.
SQL Server 2K has the BIT type which is 3-valued logic.. TRUE, FASLE or
NULL. Closed but definately no cigar........
--
Posted via http://dbforums.com
Lauri Pietarinen
Troels Arvin wrote:
>It strikes me as odd that the BOOLEAN data type is not a core requirement
>in SQL:1999 while so many other esoteric features are.
>
Interestingly, boolean is the ONLY data type required by "The Third
Manifesto" by Date & Darwen
(see www.thethirdmanifesto.com for further details).
(That must be the reason it is not part of the SQL-standard ;-) )
regards,
Lauri Pietarinen
--CELKO--
type has.
Are all the following values allowed?:
true
false
unknown
null
Does null equal unknown? <<
No, NULL is not the same as UNKNOWN and zero is not the same the empty
string. But you understand why it was left out.
There were a few reason for not having it in SQL-92.
To be a datatype in SQL, you have to be NULL-able. If you allow a
LOGICAL datatype, then it has to be TRUE, FALSE, UNKNOWN and be
NULL-able! But NULL does not work with AND, OR and NOT. Then there
is the problem that an empty scalar subquery is cast as a NULL. The
CHECK() constraint in the DDL accepts predicatres that test UNKNOWN,
while ON and WHERE in the DML do not. It gets to be a mess really
fast.
What we did give you was a predicate "<search condition> IS [NOT]
[TRUE | FALSE | UNKNOWN]" so you could test for things.
Aside from the destruction of the foundations of SQL, Booleans are
usually, but not always, a sign of bad programming. Someone is
storing the state of the database at one point in time as a flag. It
is a computed column and we all know better than to store redundant
data like that.
Paul
> Aside from the destruction of the foundations of SQL, Booleans are
> usually, but not always, a sign of bad programming.
I'm confused here! Why is it bad?
I'm working on a project where we store people's gender - what's wrong
with using a boolean for that?
> Someone is
> storing the state of the database at one point in time as a flag. It
> is a computed column and we all know better than to store redundant
> data like that.
How does one "compute" gender?
Paul...
Bob Badour
news:MPG.18f2f9fb9...@news1.eircom.net...
>
> > Aside from the destruction of the foundations of SQL, Booleans are
> > usually, but not always, a sign of bad programming.
>
> I'm confused here! Why is it bad?
>
> I'm working on a project where we store people's gender - what's wrong
> with using a boolean for that?
Because gender is neither true nor false. It is male, female, neuter,
partially transgendered, gender reassigned male to female, gender reassigned
female to male, unknown etc.
I suggest you choose an appropriate domain that represents the values of
interest and define the appropriate operations for the domain. The boolean
domain has two distinct values neither of which are male or female, and it
has operations such as conjunction and implication that have no meaning for
gender.
> > Someone is
> > storing the state of the database at one point in time as a flag. It
> > is a computed column and we all know better than to store redundant
> > data like that.
>
> How does one "compute" gender?
Personally, I have no objection to storing redundant or derived data.
Indexes do it. Snapshots do it. ... I guess I don't know who "we" is. Since
you cut the attribution, I don't even know who "he" is.
You might want to ask him what type of value a comparison operation should
return. For instance, what is the type of the following expression and what
type do the operands to the 'and' operation have?
((gender <> 'M') and (gender <> 'F'))
Of course, normalization reduces redundancy in the logical design and
thereby avoids a number of update anomalies and simplifies integrity
enforcement. But then again, base relations are not the full logical design.
Views and snapshots will introduce redundancy into the logical design as
well--automated and managed but redundant nonetheless.
To answer your question: One might derive gender a number of ways depending
on the data modelled--by counting Y chromosomes, for instance. In Ontario,
one can derive gender from a driver's license number.
Alfredo Novoa
> There were a few reason for not having it in SQL-92.
>
> To be a datatype in SQL, you have to be NULL-able. If you allow a
> LOGICAL datatype, then it has to be TRUE, FALSE, UNKNOWN and be
> NULL-able! But NULL does not work with AND, OR and NOT. Then there
> is the problem that an empty scalar subquery is cast as a NULL. The
> CHECK() constraint in the DDL accepts predicatres that test UNKNOWN,
> while ON and WHERE in the DML do not. It gets to be a mess really
> fast.
But the problems are on nulls, not on the boolean type.
> Aside from the destruction of the foundations of SQL, Booleans are
> usually, but not always, a sign of bad programming.
SQL is clearly bad founded and the boolean type is the most fundamental type of all.
If you do: select b from a where b = 0;
(b = 0) returns a boolean typed value.
SQL violates the orthogonality principle of the language design.
> Someone is
> storing the state of the database at one point in time as a flag. It
> is a computed column and we all know better than to store redundant
> data like that.
With SQL you can not have computed columns with the boolean type.
Regards
Tony
> string.
So what do we put in a NUMBER column when the value is unknown, if not
NULL - we sure don't put a zero there. As far as I ever knew, logic
only has TRUE and FALSE values. SQL has made a third option, NULL,
available - now you are saying we need 4 options (I won't say
"values"!) What would the semantic difference between NULL and
UNKNOWN be?
> There were a few reason for not having it in SQL-92.
>
> To be a datatype in SQL, you have to be NULL-able. If you allow a
> LOGICAL datatype, then it has to be TRUE, FALSE, UNKNOWN and be
> NULL-able! But NULL does not work with AND, OR and NOT. Then there
> is the problem that an empty scalar subquery is cast as a NULL. The
> CHECK() constraint in the DDL accepts predicatres that test UNKNOWN,
> while ON and WHERE in the DML do not. It gets to be a mess really
> fast.
Yes, I can see there would be problems.
> Aside from the destruction of the foundations of SQL, Booleans are
> usually, but not always, a sign of bad programming. Someone is
> storing the state of the database at one point in time as a flag. It
> is a computed column and we all know better than to store redundant
> data like that.
I would say "Booleans are sometimes, but not usually, a sign of bad
programming". Certainly I would say that using BOOLEAN to represent
gender (as someone else suggested) is a very bad idea. But in
reality, there are hundreds of well-defined columns in properly
designed databases that record a truth value of some kind, and because
of the absence of a BOOLEAN datatype have to use a kludge like (1,0)
or ('Y','N'), with the addition of a check constraint required (NB
I've never seen anyone add a third value like -1 or 'U' to represent
UNKNOWN, they'd leave it NULL). I don't think we should be denied a
useful datatype on the grounds that we're not grown up enough to use
it properly. Bad designers will just go ahead and misuse a NUMBER or
VARCHAR column instead anyway.
Paul Vernon
news:c0d87ec0.03033...@posting.google.com...
> [...] Booleans are
> usually, but not always, a sign of bad programming.
that would surprise me if it were true, but then what has programming got to
do with database theory?
> Someone is
> storing the state of the database at one point in time as a flag.
I'm not at all sure what that means
> It
> is a computed column and we all know better than to store redundant
> data like that.
Storing (uncontrolled) redundant data is indeed bad, but I can't see that
Boolean valued attributes are more likely to be storing redundant data than
say integer valued attributes.
On the other hand, I do agree that it is often better to use the presence or
absence of a row to represent some business boolean value rather than an
boolean valued attribute. Rather like attributes called 'status', there is
often more to capture about the change in value of a boolean than just the
value change itself, not least things such as the time the change occurred,
who made it and why.
Regards
Paul Vernon
Business Intelligence, IBM Global Services
Paul Vernon
news:c0e3f26e.03040...@posting.google.com...
> 71062...@compuserve.com (--CELKO--) wrote in message
news:<c0d87ec0.03033...@posting.google.com>...
> > No, NULL is not the same as UNKNOWN and zero is not the same the empty
> > string.
>
> So what do we put in a NUMBER column when the value is unknown, if not
> NULL - we sure don't put a zero there.
Well obviously if a column of domain NUMBER needs to hold the value 'unknown',
then the domain should rather be something like NUMBER_UKN. I.e. the union of
all NUMBER values and the 'unknown' value.
[...]
> (NB
> I've never seen anyone add a third value like -1 or 'U' to represent
> UNKNOWN, they'd leave it NULL).
You've obviously not seen any of my databases... I only use NULLs if someone
has a gun to my head...
> I don't think we should be denied a
> useful datatype on the grounds that we're not grown up enough to use
> it properly. Bad designers will just go ahead and misuse a NUMBER or
> VARCHAR column instead anyway.
User Defined Types anyone?
Niall Litchfield
news:b6c0ed$1inq$1...@sp15at20.hursley.ibm.com...
> "--CELKO--" <71062...@compuserve.com> wrote in message
> news:c0d87ec0.03033...@posting.google.com...
> > [...] Booleans are
> > usually, but not always, a sign of bad programming.
>
> that would surprise me if it were true, but then what has programming got
to
> do with database theory?
>
> > Someone is
> > storing the state of the database at one point in time as a flag.
>
> I'm not at all sure what that means
I *think* that the idea was apps that use (or would like to) a boolean value
for (say) SHIPPED on an order item line. There are of course other
occassions where the attribute really is a boolean, and as others have said
omitting the datatype does not prevent developers from producing roll-your
own implementations of the datatype, and then misusing them.
--
Niall Litchfield
Oracle DBA
Audit Commission UK
Troels Arvin
> It gets to be a mess really fast.
As I understand you, the primary reason for it being messy is the eternal
NULL-problem.
But then, making it optional in SQL:1999, was that perhaps a compromise?
> Aside from the destruction of the foundations of SQL, Booleans are
> usually, but not always, a sign of bad programming.
OK; good to think about.
Still, I think that there are many conceivable relations were
true/false/unknown makes good sense. So my question then becomes "what's a
good, cross-DBMS-product way of doing it; it there perhaps a de-facto
standard for doing it?". The ways I see:
a) As a boolean field
---------------------
Fails in important SQL implemetations like Oracle and MSSQL. Works in
PostgreSQL. Fails in Mimer SQL.
b) As a one-char bit string
---------------------------
Fails in Oracle and Mimer SQL.
Works differently between PostgreSQL and MSSQL:
MSSQL:
troels@jtds:windows> create table test(id int not null primary key, truth
bit);
affected 0 rows (6 msec)
troels@jtds:windows> insert into test values(42,0);
affected 1 rows (7 msec)
troels@jtds:windows> insert into test values(43,1);
affected 1 rows (2 msec)
troels@jtds:windows> insert into test values(44,B'1');
FAILURE: The name 'B' is not permitted in this context. Only
constants, expressions, or variables allowed here. Column
names are not permitted.
troels@jtds:windows> select * from test;
----+-------+
id | truth |
----+-------+
42 | false |
43 | true |
----+-------+
2 rows in result (first row: 7 msec; total: 8 msec)
PostgreSQL:
troels=> create table test(id int not null primary key,truth bit);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
'test_pkey' for table 'test'
CREATE TABLE
troels=> insert into test values(42,0);
ERROR: column "truth" is of type bit but expression is of type
integer
You will need to rewrite or cast the expression
troels=> insert into test values(43,1);
ERROR: column "truth" is of type bit but expression is of type
integer
You will need to rewrite or cast the expression
troels=> insert into test values(44,B'1'); INSERT 19180 1
troels=> select * from test;
id | truth
----+-------
44 | 1
(1 row)
c) As a magic char/value
In any database that I know of (except for MySQL[1]), one may use an
ordinary type like char(1) or int combined with a CHECK in order to restrict
the domain of values.
The portability of this solution makes it nice, but magic values are a bad
habit in my opinion, primarily because of the lack consensus this results
in (is it 0 or 'F' or 'f' or 'FALSE' or 'false' or 'n' or 'no' or 'N' or
'NO', ...).
I wonder if DB2 supports the boolean or bit types.
/Troels
Note 1: In MySQL, one may use ENUMs to achieve the same situation, but it
ties you to MySQL which makes it a bad choise.
Paul Vernon
[snip]
>
> I wonder if DB2 supports the boolean or bit types.
Not externally:
C:\SQLLIB\BIN>db2 create table bool(b boolean not null primary key)
SQL0486N The BOOLEAN data type is currently only supported internally.
SQLSTATE=42991
And we don't have a BIT type. Have to use CHAR(1) or maybe DECIMAL(1,0) plus
CHECK constraints to simulate BOOLEAN.
Costin Cozianu
That's news to me :) First it's news that SQL had foundations. If it was
founded on relational model, than not only a boolean data type would be
unharmful, but would be almost mandatory.
Aside from the above quibble, it's socking news to me that booleans are
sign of bad programming. On the contrary, lack of booleans is a sign of
bad programming, and lack of support for boolean data type is a sign of
bad language design.
You should really go read up on good old Dijsktra, he knew a few things
about programming ...
Google for EWD1284
Bob Badour
> That's news to me :) First it's news that SQL had foundations. If it was
> founded on relational model, than not only a boolean data type would be
> unharmful, but would be almost mandatory.
>
> Aside from the above quibble, it's socking news to me that booleans are
> sign of bad programming. On the contrary, lack of booleans is a sign of
> bad programming, and lack of support for boolean data type is a sign of
> bad language design.
>
> You should really go read up on good old Dijsktra, he knew a few things
> about programming ...
>
> Google for EWD1284
He did indeed know a few things about programming. An excellent and
enjoyable read--thanks for suggesting it.
WangKhar
There is a definite difference between unknown and null.
Unknown (to me at least) suggests you Dont Know. Null itself suggests
you dont know whether you know or not.
as it were...
its a literal null state of knowledge, as opposed to unknown which is
a positive denial of knowledge.
try posting in a philosophy group for a serious answer on that one....
:P is there a database.philosophy group out there?
andrewst
Originally posted by Wangkhar
IKNOWBUTIMNOTSAYING and MAYBEIKNOWMAYBEIDONT and
IBELIEVEITSTRUEBUTNOT100%CERTAIN, ...
Paul Vernon
news:cd3b3cf.03040...@posting.google.com...
I'll second that.
Also it was pleasing, but hardly surprising to find that Edsger saying "I do
not think that object orientated programming ... meets my standards of
elegance"
Mikito Harakiri
"andrewst" <membe...@dbforums.com> wrote in message
news:2719298.1...@dbforums.com...
> > Unknown (to me at least) suggests you Dont Know. Null itself suggests
> > you dont know whether you know or not.
> >
> I like it. Maybe we need further Boolean values like
> IKNOWBUTIMNOTSAYING and MAYBEIKNOWMAYBEIDONT and
> IBELIEVEITSTRUEBUTNOT100%CERTAIN, ...
Seriously, it is very rare for a database developer who reverse engineers
the existing database to ask what the NULL in the given column means. More
often they ask what is the semantics of the column itself, as (s)he have to
guess the meaning from the name of the column alone.
In practice, it is common to have tables with 100 fields. Then, a record
entry clerk perspective for the NULL is
DONTBOTHERMEWITHTHISSTUPIDFIELD
-- I just want to complete the entry form as soon as possible...
Bob Badour
news:bb269444.03040...@posting.google.com...
> On the true false unknown null question.
>
> There is a definite difference between unknown and null.
>
> Unknown (to me at least) suggests you Dont Know. Null itself suggests
> you dont know whether you know or not.
NULL means different things to different people and different things to the
same person in different contexts. In SQL, the semantics sometimes match
"unknown" and at other times have truly absurd semantics forcing implicit
restriction criteria etc.
Codd tried to plaster over the problems by introducing a second marker for
"inapplicable" and further complicating the logic type to use 4VL. Date
rightly criticized that at the time for starting the way to an infinite
progression of markers.
I see that you and Andrew are "reinventing the wheel" of sorts--or perhaps
better "reexploring the back yard".
--CELKO--
In the old days of unit record equipment (aka "punch cards"), you had
to put data in the fields and then run the deck thru various machines
to sort and tabulate them. One of the standard machines did
computations and punched the results into columns in the same card.
Usually, it was things like "(quantity * price) = extension".
This sytle of programming carried over to magnetic tapes and into
sequential files. We would compute and record the total of the order
details in a header record and often a flag was set to record the
state of the group in that record -- say the total order was high
enough to qualify for a discount, so we set a bit.
If an order item changed, you had problems and had to go back and
re-set the flags. Eventually, the flag would get out of synch with
the set of records that it was supposed to summarize. Opps!
So when we got to RDBMS systems, we tried to get rid of redundancies
like that with normalization.
>>I'm working on a project where we store people's gender - what's
wrong
with using a boolean for that? <<
There is an ISO Standard code for gender and you should use Standards
whenever they exists.
0= unknown
1= male
2= female
9= N/A, lawful person such as a church, school, corporation
Gender is not a flag; it is an attribute. A flag reports a state, an
attribute takes a value.
--CELKO--
If you had a "Chris Date Database" without NULLs, you would not need
the 3VL and could build a consistent model. But here in the real
world, we are using SQL.
>> SQL is clearly bad founded and the boolean type is the most
fundamental type of all. <<
No, it is more complex to try to model the real world, where you don't
have perfect knowledge and attributes can be missing. There are many
versions of Geometry -- on a plane, a triangle always has 360 degrees;
on the surface of a sphere, a triangle always has more than 360
degrees; on the surface of a hyperbola, a triangle always has less
than 360 degrees. The Catholic Church in the Middle Ages was sure
that ONLY Euclid was right. This made navigation with a round Earth
into heresy.
--CELKO--
NULL is a marker for a value; UNKNOWN is a logical value.
>> I would say "Booleans are sometimes, but not usually, a sign of bad
programming". <<
My experience has been "usually" -- the programs I have seen are still
thinking in terms of assembly and 'C' level programming. People
really do things like BOOLEAN gender! Yes, there are two-valued
attributes in reality, but it is better to use a domain that it
immediately obvious to a human reader -- most of the time we settle
for sex IN ('m', 'f') instead of TRUE/FALSE (see my other post about
the ISO gender codes).
>> Bad designers will just go ahead and misuse a NUMBER or VARCHAR
column instead anyway. <<
Amen.
--CELKO--
boolean value
for (say) SHIPPED on an order item line. <<
And we need to know the actual ship date, so let's put in a column for
that. Now the SHIPPED bit is redudant. Actually dangerous; someone
sets the flag but doe snto give a date, or gives a date, but does not
set the flag. One program uses the flag, another uses the date to get
totals. We're screwed.
Costin Cozianu
Let all threads in comp.database.theory get a identifying key (let's say
the one used by groups.google.com web application for lack of easier
references ).
Let there be a a panel of judges who will "judge" if Joe Celko's
contributions to the above threads are "good" as opposed to "bad"
(unreasonable, misleading, containing bad advice). So we want to trak
basic facts like this:
Costin Cozianu thinks that Joe Celko's contribution to the <BOOLEAN
Data type thread> is not good.
The final purpose would probably be to run some statistics :)
Here's a minimal and natural solution with the boolean data types. I
leave the constraints as an exercise for the reader, because you made
SQL way too verbose for me to bother :)
CREATE TABLE THREADS (
thread_id varchar,
thread_subject varchar)
CREATE TABLE JUDGES (
judge varchar
)
CREATE TABLE JUDGEMENTS (
thread_id varchar,
judge varchar,
is_good boolean
)
and then I'd insert for this particular thread:
INSERT INTO JUDGEMENTS
VALUES ( 'W1Hia.19%243l2.962647%40mantis.golden.net', 'Costin
Cozianu', false )
If I want to say that your contribution is good I'd put a "true". If I
am in doubts or have mixed feelings, I don't want to pronounce, I won't
insert anything.
Voila: a natural usage of boolean datatype, *and* there are no NULLs in
the table, and no NULLs are ever needed in this case. Plus the schema is
very easy to use in programs, queries, reports, OLAP thingies :)
Lauri Pietarinen
> You should really go read up on good old Dijsktra, he knew a few things
> about programming ...
>
> Google for EWD1284
Thanks! Does anybody know if EWD contributed any
database stuff? Strange that he does not mention databases
in his keynote.
Lauri
Dieter Nöth
> Let there be a a panel of judges who will "judge" if Joe Celko's
> contributions to the above threads are "good" as opposed to "bad"
> (unreasonable, misleading, containing bad advice).
You already say that there are many different "bads", so why not using
different values indicating "unreasonable", "misleading", "containing
bad advice", "good", "excellent"... instead of black/white, yes/no?
Or similar to school marks "A" to "F"?
> Here's a minimal and natural solution with the boolean data types. I
> leave the constraints as an exercise for the reader, because you made
> SQL way too verbose for me to bother :)
>
> CREATE TABLE THREADS (
> thread_id varchar,
> thread_subject varchar)
>
> CREATE TABLE JUDGES (
> judge varchar
> )
>
> CREATE TABLE JUDGEMENTS (
> thread_id varchar,
> judge varchar,
> is_good boolean
> )
>
> and then I'd insert for this particular thread:
>
> INSERT INTO JUDGEMENTS
> VALUES ( 'W1Hia.19%243l2.962647%40mantis.golden.net', 'Costin
> Cozianu', false )
>
> If I want to say that your contribution is good I'd put a "true". If I
> am in doubts or have mixed feelings, I don't want to pronounce, I won't
> insert anything.
>
> Voila: a natural usage of boolean datatype, *and* there are no NULLs in
> the table, and no NULLs are ever needed in this case. Plus the schema is
> very easy to use in programs, queries, reports, OLAP thingies :)
If you don't insert anything it's a NULL ;-)
Dieter
Alfredo Novoa
> >> I *think* that the idea was apps that use (or would like to) a
> boolean value
> for (say) SHIPPED on an order item line. <<
>
> And we need to know the actual ship date, so let's put in a column for
> that. Now the SHIPPED bit is redudant.
In that case the SHIPPED attribute should be a derived attribute. But
you can not do that with SQL.
In a recent database design I used a PRINTED boolean attribute, and
the customer is not interested on the actual print date.
I have another boolean attribute called InDeposit.
> Actually dangerous; someone
> sets the flag but doe snto give a date, or gives a date, but does not
> set the flag.
Derived attributes and integrity constraints are for that.
Regards
Alfredo
Costin Cozianu
> Costin Cozianu wrote:
>
>> Let there be a a panel of judges who will "judge" if Joe Celko's
>> contributions to the above threads are "good" as opposed to "bad"
>> (unreasonable, misleading, containing bad advice).
>
>
> You already say that there are many different "bads", so why not using
> different values indicating "unreasonable", "misleading", "containing
> bad advice", "good", "excellent"... instead of black/white, yes/no?
> Or similar to school marks "A" to "F"?
>
Because the user doesn't care. He needs to know good just if the
contribution is good. Tons of real life applications with true/false is
in distributed knowledge management applications.
Let there be a proposition P, we want to know if agent X considers the
propositions true/false or just he can't tell.
Refining the specifications beyond what the user needs and asks for is
bad practice.
Not quite. An empty set is very different from NULL in many aspects, not
the least of which is that it poses absolutely no complication to basic
logic and set theory.
Costin
--CELKO--
But
you can not do that with SQL. <<
Unh??? Assuming the usual trick of a NULL for an unknown future
date:
SELECT order_nbr, CASE WHEN shipped_date IS NOT NULL
THEN 'yes' ELSE 'No ' END AS shipped_flag
FROM Orders;
>> In a recent database design I used a PRINTED boolean attribute, and
the customer is not interested on the actual print date. <<
Yet; wait until he has to do an audit trail. People almost alway ask
"When" if they are talking about an event that has legal consequences.
>> Derived attributes and integrity constraints are for that. <<
So, we put redundancy in the table design, then add extra constriants
to maintain it? Bad idea!
Bob Badour
news:b6gr24$5797t$1...@ID-28204.news.dfncis.de...
An empty set is different from NULL. Perhaps, you should pay more attention
to Costin and less attention to Joe.
Bob Badour
news:e9d83568.03040...@posting.google.com...
Whether he wrote anything specific to databases is unknown to me, but he
wrote tons of stuff applicable to databases including his most famous stuff
like shortest path and critical sections/concurrency. In fact, I am sure
almost everything he wrote could have some relevance to database management
systems, since these systems generally comprise one or more program -- among
other things.
Simply by searching for Codd and Dijkstra I quickly found this:
http://citeseer.nj.nec.com/context/88414/0
Searching the index at http://www.cs.utexas.edu/users/EWD/indexBibTeX.html I
found no mentions of the term database. I do not know what the dutch would
be. Searching for "calculus", I got the following likely relevant hits:
EWD418
EWD863
EWD905
EWD910
EWD912
EWD928
EWD949
EWD969
EWD982
EWD1001
EWD1002
EWD1060
EWD1061
EWD1114
Alfredo Novoa
>
> If you had a "Chris Date Database" without NULLs, you would not need
> the 3VL and could build a consistent model.
I have two, and yes it is a lot more consistent model.
> >> SQL is clearly bad founded and the boolean type is the most
> fundamental type of all. <<
>
> No, it is more complex to try to model the real world, where you don't
> have perfect knowledge and attributes can be missing.
I don't see your point.
> There are many
> versions of Geometry -- on a plane, a triangle always has 360 degrees;
> on the surface of a sphere, a triangle always has more than 360
> degrees; on the surface of a hyperbola, a triangle always has less
> than 360 degrees.
The above statements are True, a boolean typed value :)
> The Catholic Church in the Middle Ages was sure
> that ONLY Euclid was right. This made navigation with a round Earth
> into heresy.
And what is the relation with the boolean type?
For instance I could create a relation variable like this:
var Statements real relation { Statement Char, IsHeresy Boolean }
key { Statement };
And to assign a value to it like this:
Statements := relation {
tuple { Statement 'Navigation with a round Earth', IsHeresy True },
tuple { Statement 'Earth is flat', IsHeresy False }
};
The veracity of the propositions is my problem, the DBMS only have to
check the consistency of the propositions, and they are consistent.
Regards
Alfredo Novoa
> But
> you can not do that with SQL. <<
>
> Unh??? Assuming the usual trick of a NULL for an unknown future
> date:
>
> SELECT order_nbr, CASE WHEN shipped_date IS NOT NULL
> THEN 'yes' ELSE 'No ' END AS shipped_flag
> FROM Orders;
But 'yes' is not a boolean value, it is a character string.
If you want the relation of unshipped orders then you need a little
trick:
select * from orders where shipped_flag = 'No ';
With a "Date DBMS" it could be:
orders where not shipped;
A lot more elegant and less error prone.
> >> In a recent database design I used a PRINTED boolean attribute, and
> the customer is not interested on the actual print date. <<
>
> Yet; wait until he has to do an audit trail. People almost alway ask
> "When" if they are talking about an event that has legal consequences.
It is not the case, at least in my country.
> >> Derived attributes and integrity constraints are for that. <<
>
> So, we put redundancy in the table design, then add extra constriants
> to maintain it? Bad idea!
It is not a bad idea if the redundancy is controlled by the DBMS, like
when you use views.
For instance: the actual stock of an article is redundant data, but I
would like to do this:
select id, actual_stock from articles;
Of course we don't need redundancy on base relvars in order to do
that.
Regards
Alfredo
Alfredo Novoa
Sorry.
When I said "actual stock", I meant "current stock".
"stock actual" is the Spanish for "current stock" O:)
Lauri Pietarinen
> Whether he wrote anything specific to databases is unknown to me, but he
> wrote tons of stuff applicable to databases including his most famous stuff
> like shortest path and critical sections/concurrency. In fact, I am sure
> almost everything he wrote could have some relevance to database management
> systems, since these systems generally comprise one or more program -- among
> other things.
What I was actually wondering was how come he has not
realised the power and relevance of relational db theory
to the things he strives for (simplicity, fighting complexity,
elegance etc etc). At least
he does not mention the theory in his keynote. Do we
have yet another programmer, who does not understand
databases? ;-)
regards,
Lauri Pietarinen
Paul
bba...@golden.net says...
> > I'm confused here! Why is it bad?
> > I'm working on a project where we store people's gender - what's wrong
> > with using a boolean for that?
> Because gender is neither true nor false.
What about a field HasYChromosome - and please don't tell me about
various chromosomal disorders that can lead to attributes of maleness
despite having no Y chromosome or vice versa - this has little relevance
in the real world.
> It is male, female, neuter,
> partially transgendered, gender reassigned male to female, gender reassigned
> female to male, unknown etc.
This is essentially meaningless in the real world - "You've just had a
baby - boy or girl?" - not "Is it male, female, partially transgendered,
gender reassigned male to female, gender reassigned female to male,
unknown etc."
Knowing the sex of the person in the case of an app I'm working on at
the moment is important, since it is potentially necessary for possible
dormitory sleeping arrangements - i.e. the boys sleep in dorms with
other boys and vice versa.
> I suggest you choose an appropriate domain that represents the values of
> interest and define the appropriate operations for the domain. The boolean
> domain has two distinct values neither of which are male or female, and it
> has operations such as conjunction and implication that have no meaning for
> gender.
What about a table which stores bills? Paid or unpaid - that's a fairly
simple and important example of a boolean.
> > How does one "compute" gender?
> Personally, I have no objection to storing redundant or derived data.
> Indexes do it. Snapshots do it. ... I guess I don't know who "we" is. Since
> you cut the attribution, I don't even know who "he" is.
The person to whom I was replying was Mr Celko IIRC.
> To answer your question: One might derive gender a number of ways depending
> on the data modelled--by counting Y chromosomes, for instance. In Ontario,
> one can derive gender from a driver's license number.
And in France, it's part of the Social Security number. Alors?
Paul...
--
plinehan__AT__yahoo__DOT__com
Paul
71062...@compuserve.com says...
> >>I'm working on a project where we store people's gender - what's
> >> wrong with using a boolean for that?
> There is an ISO Standard code for gender and you should use Standards
> whenever they exists.
> 0= unknown
> 1= male
> 2= female
> 9= N/A, lawful person such as a church, school, corporation
When you're doing a system for Youth Hostel memberships, 1 and 2 are all
you'll really need!
> Gender is not a flag; it is an attribute. A flag reports a state, an
> attribute takes a value.
OK then, what about Table Billing(blah...., Paid BOOLEAN NOT NULL,
blah...)
Is this not a valid use of a Boolean field?
Paul...
--
plinehan__AT__yahoo_DOT_com
Bob Badour
news:e9d83568.03040...@posting.google.com...
>
> > Whether he wrote anything specific to databases is unknown to me, but he
> > wrote tons of stuff applicable to databases including his most famous
stuff
> > like shortest path and critical sections/concurrency. In fact, I am sure
> > almost everything he wrote could have some relevance to database
management
> > systems, since these systems generally comprise one or more program --
among
> > other things.
>
> What I was actually wondering was how come he has not
> realised the power and relevance of relational db theory
> to the things he strives for (simplicity, fighting complexity,
> elegance etc etc).
I would say that he did not limit the utility of predicate calculus to only
databases. If you start spelunking through his EWD's, you will see that he
sought to prove theorems without reference to their use so that their use is
not limited.
> At least
> he does not mention the theory in his keynote. Do we
> have yet another programmer, who does not understand
> databases? ;-)
He went to the trouble of saying he did not find object orientation elegant.
(A condemnation that applies at least as much to using OO for programming as
it does to using it for data management.) It is hopeful that he did not
single out the relational model for comment.
Because he was a student of programming, perhaps, he chose not to comment on
data management. Alas, we can no longer ask him.
I would never presume that E.W.Dijkstra misunderstood anything important
related to computing.
Bob Badour
news:e9d83568.03040...@posting.google.com...
>
> > Whether he wrote anything specific to databases is unknown to me, but he
> > wrote tons of stuff applicable to databases including his most famous
stuff
> > like shortest path and critical sections/concurrency. In fact, I am sure
> > almost everything he wrote could have some relevance to database
management
> > systems, since these systems generally comprise one or more program --
among
> > other things.
>
> What I was actually wondering was how come he has not
> realised the power and relevance of relational db theory
> to the things he strives for (simplicity, fighting complexity,
> elegance etc etc).
I would say that he did not limit the utility of predicate calculus to only
databases. If you start spelunking through his EWD's, you will see that he
sought to prove theorems without reference to their use so that their use is
not limited.
> At least
> he does not mention the theory in his keynote. Do we
> have yet another programmer, who does not understand
> databases? ;-)
He went to the trouble of saying he did not find object orientation elegant.
Bob Badour
news:e9d83568.03040...@posting.google.com...
>
> > Whether he wrote anything specific to databases is unknown to me, but he
> > wrote tons of stuff applicable to databases including his most famous
stuff
> > like shortest path and critical sections/concurrency. In fact, I am sure
> > almost everything he wrote could have some relevance to database
management
> > systems, since these systems generally comprise one or more program --
among
> > other things.
>
> What I was actually wondering was how come he has not
> realised the power and relevance of relational db theory
> to the things he strives for (simplicity, fighting complexity,
> elegance etc etc).
I would say that he did not limit the utility of predicate calculus to only
databases. If you start spelunking through his EWD's, you will see that he
sought to prove theorems without reference to their use so that their use is
not limited.
> At least
> he does not mention the theory in his keynote. Do we
> have yet another programmer, who does not understand
> databases? ;-)
He went to the trouble of saying he did not find object orientation elegant.
Bob Badour
news:MPG.18f7b403e...@news1.eircom.net...
>
> bba...@golden.net says...
>
> > > I'm confused here! Why is it bad?
>
> > > I'm working on a project where we store people's gender - what's wrong
> > > with using a boolean for that?
>
> > Because gender is neither true nor false.
>
> What about a field HasYChromosome - and please don't tell me about
> various chromosomal disorders that can lead to attributes of maleness
> despite having no Y chromosome or vice versa - this has little relevance
> in the real world.
HasYChromosome is properly boolean. One must presume that the business rules
do not need to record multiple Y chromosomes, and that the application cares
more about what the chromosomes say than what the sexual organs say--or what
the person says, for that matter. Someone transgendered from female to male
might not have a Y chromosome, but might use the mens room.
> > It is male, female, neuter,
> > partially transgendered, gender reassigned male to female, gender
reassigned
> > female to male, unknown etc.
>
> This is essentially meaningless in the real world - "You've just had a
> baby - boy or girl?" - not "Is it male, female, partially transgendered,
> gender reassigned male to female, gender reassigned female to male,
> unknown etc."
You presume much. I would argue that those struggling with the legal and
social ramifications of transgender surgery--in the real world--would
disagree with your broad generality.
> Knowing the sex of the person in the case of an app I'm working on at
> the moment is important, since it is potentially necessary for possible
> dormitory sleeping arrangements - i.e. the boys sleep in dorms with
> other boys and vice versa.
Where do you put the intersexed children? At 1:1000 to 1:500, your
application will probably have to deal with the situation eventually:
http://home.vicnet.net.au/~aissg/intersexq&a.htm
Where do you put the sexually aggressive abuse survivors?
http://www.csun.edu/~psy453/expose_y.htm
What does the implication function mean for gender?
> > I suggest you choose an appropriate domain that represents the values of
> > interest and define the appropriate operations for the domain. The
boolean
> > domain has two distinct values neither of which are male or female, and
it
> > has operations such as conjunction and implication that have no meaning
for
> > gender.
>
> What about a table which stores bills? Paid or unpaid - that's a fairly
> simple and important example of a boolean.
I agree, and I would observe that the boolean functions actually have some
meaning for "paid" as in the following boolean expression:
(invoiced and not paid)
Bob Badour
news:e9d83568.03040...@posting.google.com...
>
> > Whether he wrote anything specific to databases is unknown to me, but he
> > wrote tons of stuff applicable to databases including his most famous
stuff
> > like shortest path and critical sections/concurrency. In fact, I am sure
> > almost everything he wrote could have some relevance to database
management
> > systems, since these systems generally comprise one or more program --
among
> > other things.
>
> What I was actually wondering was how come he has not
> realised the power and relevance of relational db theory
> to the things he strives for (simplicity, fighting complexity,
> elegance etc etc).
I would say that he did not limit the utility of predicate calculus to only
databases. If you start spelunking through his EWD's, you will see that he
sought to prove theorems without reference to their use so that their use is
not limited.
> At least
> he does not mention the theory in his keynote. Do we
> have yet another programmer, who does not understand
> databases? ;-)
He went to the trouble of saying he did not find object orientation elegant.
Bob Badour
>
> > > I'm confused here! Why is it bad?
>
> > > I'm working on a project where we store people's gender - what's wrong
> > > with using a boolean for that?
>
> > Because gender is neither true nor false.
>
> What about a field HasYChromosome - and please don't tell me about
> various chromosomal disorders that can lead to attributes of maleness
> despite having no Y chromosome or vice versa - this has little relevance
> in the real world.
HasYChromosome is properly boolean. One must presume that the business rules
do not need to record multiple Y chromosomes, and that the application cares
more about what the chromosomes say than what the sexual organs say--or what
the person says, for that matter. Someone transgendered from female to male
might not have a Y chromosome, but might use the mens room.
> > It is male, female, neuter,
> > partially transgendered, gender reassigned male to female, gender
reassigned
> > female to male, unknown etc.
>
> This is essentially meaningless in the real world - "You've just had a
> baby - boy or girl?" - not "Is it male, female, partially transgendered,
> gender reassigned male to female, gender reassigned female to male,
> unknown etc."
You presume much. I would argue that those struggling with the legal and
social ramifications of transgender surgery--in the real world--would
disagree with your broad generality.
> Knowing the sex of the person in the case of an app I'm working on at
> the moment is important, since it is potentially necessary for possible
> dormitory sleeping arrangements - i.e. the boys sleep in dorms with
> other boys and vice versa.
Where do you put the intersexed children? At 1:1000 to 1:500, your
application will probably have to deal with the situation eventually:
http://home.vicnet.net.au/~aissg/intersexq&a.htm
Where do you put the sexually aggressive abuse survivors?
http://www.csun.edu/~psy453/expose_y.htm
What does the implication function mean for gender?
> > I suggest you choose an appropriate domain that represents the values of
> > interest and define the appropriate operations for the domain. The
boolean
> > domain has two distinct values neither of which are male or female, and
it
> > has operations such as conjunction and implication that have no meaning
for
> > gender.
>
> What about a table which stores bills? Paid or unpaid - that's a fairly
> simple and important example of a boolean.
I agree, and I would observe that the boolean functions actually have some
Paul
71062...@compuserve.com says...
> >>I'm working on a project where we store people's gender - what's
> >> wrong with using a boolean for that?
> There is an ISO Standard code for gender and you should use Standards
> whenever they exists.
> 0= unknown
> 1= male
> 2= female
> 9= N/A, lawful person such as a church, school, corporation
When you're doing a system for Youth Hostel memberships, 1 and 2 are all
you'll really need!
> Gender is not a flag; it is an attribute. A flag reports a state, an
> attribute takes a value.
OK then, what about Table Billing(blah...., Paid BOOLEAN NOT NULL,
Paul
bba...@golden.net says...
> > What about a field HasYChromosome - and please don't tell me about
> > various chromosomal disorders that can lead to attributes of maleness
> > despite having no Y chromosome or vice versa - this has little relevance
> > in the real world.
> HasYChromosome is properly boolean. One must presume that the business rules
> do not need to record multiple Y chromosomes,
And there would be precious few apps that would need this!
> and that the application cares
> more about what the chromosomes say than what the sexual organs say--or what
> the person says, for that matter. Someone transgendered from female to male
> might not have a Y chromosome, but might use the mens room.
But would call themselves "male" and look "reasonably" male and have
something resembling a willy and use the men's room and be able to sleep
in the male dorm - even if they were lacking in the willy dept., there's
nothing obliging people to strip off in dorms.
> > This is essentially meaningless in the real world - "You've just had a
> > baby - boy or girl?" - not "Is it male, female, partially transgendered,
> > gender reassigned male to female, gender reassigned female to male,
> > unknown etc."
> You presume much. I would argue that those struggling with the legal and
> social ramifications of transgender surgery--in the real world--would
> disagree with your broad generality.
I am writing an application for the real world, not the far out
scenarios you are describing.
> > Knowing the sex of the person in the case of an app I'm working on at
> > the moment is important, since it is potentially necessary for possible
> > dormitory sleeping arrangements - i.e. the boys sleep in dorms with
> > other boys and vice versa.
> Where do you put the intersexed children? At 1:1000 to 1:500, your
> application will probably have to deal with the situation eventually:
> http://home.vicnet.net.au/~aissg/intersexq&a.htm
Intersexes generally resemble one or the other and are treated as such.
> Where do you put the sexually aggressive abuse survivors?
> http://www.csun.edu/~psy453/expose_y.htm
If one wanders in off the street to join a Youth Hostel Organisation, I
doubt if anyone's going to ask me about any history of sexual abuse.
> What does the implication function mean for gender?
Eh?
> > What about a table which stores bills? Paid or unpaid - that's a fairly
> > simple and important example of a boolean.
> I agree, and I would observe that the boolean functions actually have some
> meaning for "paid" as in the following boolean expression:
> (invoiced and not paid)
Indeed, which is why I asked in the first place.
Paul...
--
plinehan__AT__yahoo_DOT_com
Bob Badour
>
> bba...@golden.net says...
>
> > > What about a field HasYChromosome - and please don't tell me about
> > > various chromosomal disorders that can lead to attributes of maleness
> > > despite having no Y chromosome or vice versa - this has little
relevance
> > > in the real world.
>
> > HasYChromosome is properly boolean. One must presume that the business
rules
> > do not need to record multiple Y chromosomes,
>
> And there would be precious few apps that would need this!
So says you. I have worked on applications for genetic counsellors, and they
might disagree. With ever more rapid advances in medicine and in
understanding human genetics, this sort of thing will only get more
important.
Someday, someone might have to design a data model for an application that
accounts for chimeras as well. While rare, such people do exist.
> > and that the application cares
> > more about what the chromosomes say than what the sexual organs say--or
what
> > the person says, for that matter. Someone transgendered from female to
male
> > might not have a Y chromosome, but might use the mens room.
>
> But would call themselves "male" and look "reasonably" male and have
> something resembling a willy and use the men's room and be able to sleep
> in the male dorm - even if they were lacking in the willy dept., there's
> nothing obliging people to strip off in dorms.
You can make up whatever requirements you want to try to justify your bad
design suggestion. Neither male nor female is true and HasYChromosome
necessarily help you to assign dormitories.
I would suggest a Dormitory domain and an AssignedDormitory attribute. That
way, you could have as many dormitories as you need and assign them any
number of ways.
> > > This is essentially meaningless in the real world - "You've just had a
> > > baby - boy or girl?" - not "Is it male, female, partially
transgendered,
> > > gender reassigned male to female, gender reassigned female to male,
> > > unknown etc."
>
>
> > You presume much. I would argue that those struggling with the legal and
> > social ramifications of transgender surgery--in the real world--would
> > disagree with your broad generality.
>
>
> I am writing an application for the real world, not the far out
> scenarios you are describing.
In your real-world application, neither male nor female is true and
HasYChromosome will not suffice for assigning dormitories. In any case, I
was addressing your sweeping generality regarding meaning in the real world
and not the specific requirements of your application, which are of course
just as meaningless to most of the real world.
> > > Knowing the sex of the person in the case of an app I'm working on at
> > > the moment is important, since it is potentially necessary for
possible
> > > dormitory sleeping arrangements - i.e. the boys sleep in dorms with
> > > other boys and vice versa.
>
>
> > Where do you put the intersexed children? At 1:1000 to 1:500, your
> > application will probably have to deal with the situation eventually:
> > http://home.vicnet.net.au/~aissg/intersexq&a.htm
>
>
> Intersexes generally resemble one or the other and are treated as such.
What if the intersexed child protests?
> > Where do you put the sexually aggressive abuse survivors?
> > http://www.csun.edu/~psy453/expose_y.htm
>
> If one wanders in off the street to join a Youth Hostel Organisation, I
> doubt if anyone's going to ask me about any history of sexual abuse.
In that case, it might be safer to arrange sleeping arrangements some other
way.
> > What does the implication function mean for gender?
>
> Eh?
Implication has meaning as a binary operation on boolean values. What
meaning does it have for gender if gender is a boolean value?
> > > What about a table which stores bills? Paid or unpaid - that's a
fairly
> > > simple and important example of a boolean.
>
> > I agree, and I would observe that the boolean functions actually have
some
> > meaning for "paid" as in the following boolean expression:
> > (invoiced and not paid)
>
> Indeed, which is why I asked in the first place.
That wasn't what you asked in the first place--at least not the first place
I saw. In the first place, you asked why boolean is an inappropriate domain
for gender. You don't seem particularly willing to accept the answer to the
question, though.
Monte Gardner
Or, as in the case of a small School project I recently completed,
let's say you have a table of product orders and you need to know
which one's have been shipped and which one's haven't.
That's a boolean value that can't be computed from other data.
Alan
news:ee5e1a69.03040...@posting.google.com...
Sure it can- from Shipped_Date:
IF Shipped_Date <= Today, then it's been shipped
Else If Shipped_Date > Today, it has not yet been shipped,
Else If Shipped_Date IS NULL, then we just don't know, but it looks like
shipping is not in the works...
--CELKO--
which one's have been shipped and which one's haven't. That's a
boolean value that can't be computed from other data. <<
Wrong:
CREATE TABLE Orders
(order_nbr INTEGER NOT NULL PRIMARY KEY,
..
ship_date DATE, -- null means not yet shipped
..);
And please don't tell that you would not record the shipping date,
shipping charges, shipping method, etc. in the database.
GoranG
wrote:
Hm, please do tell why is a good thing that standard forces you to put
in to your physical model fields that are not needed (for some
business rules storing such property might even be _forbidden_ !)?
I do agree that storing a ship_date (shipping date) makes data more
meaningful and is a good thing in 91,7%, or so, cases.
However the principle is not ok.. you can _not_ know (in 100% cases)
weather I _need_ or _am able_ (without additional costs) to store
shipping charges, shipping method, etc.!
You can't even know if I am allowed to store this or similar surrogate
constructs.
Standard should not force you to do so...
Also, we _are_ talking about standard and physical implementation of
the database where redundancy is acceptable AFAIK.
If my model only cares about Female property for an entity, and if
this property has domain (True, False) in my model's semantics and I
do not need to generalize into obvious then shouldn't I be allowed to
model as such?
Sure, I might want to capture more meaning, but what if I can't?
Simple example:
I store a result of test and a date/time of this test for a particular
individual. This test tells me if this individual is female or not.
This is all I need to know. Period.
And sure - one can always store boolean values as expression:
(some property = some value), but isn't this complexity overhead in
general?
All the best
( GoranG79 AT hotmail.com )
Alan
news:c0d87ec0.03040...@posting.google.com...
So, you are saying NULL may have a valid semantic meaning? Doesn't NULL (in
this example) mean, "have not a clue, maybe it was shipped, maybe it wasn't,
maybe it will be shipped one day..."? Shouldn't it work like this:
IF Shipping_Date <= Today, then it's been shipped
Else If Shipping_Date > Today, it has not yet been shipped, but apparently
will be on the given date
Else If Shipping_Date IS NULL, then we just don't know...
--CELKO--
meaningful and is a good thing in 91,7%, or so, cases. <<
Accounting will not work without it! This example is a 100%
requirement.
>> However the principle is not ok ... If my model only cares about
Female property for an entity, and if this property has domain (True,
False) in my model's semantics ... <<
This is a bad data model; clearly "female" is a value of an attribute;
the domain is "gender". Why do you want to find ways to do bad data
models? N. Wirth said it very nicely: "A good language should make
good programming easier and bad programming harder".
>> And sure - one can always store boolean values as expression: (some
property = some value), but isn't this complexity overhead in general?
<<
That is not complexity; that is reality <g>! A Boolean is too general
to carry much meaning.
Bob Badour
news:b717p3$a176q$1...@ID-114862.news.dfncis.de...
What happens if something goes wrong and the item doesn't ship on the
anticipated date? Hmmmm.... I guess you might need a boolean, after all, to
indicate whether the item actually shipped.
Alan
Not really. It depends on the semantics of the attribute (shippED_date
(infers past dates only) vs. shippING_date (infers any date), E.g. ), and
how one wants to handle the situation. It boils down to business rules,
which is what the database is there to serve. So, for example, the business
decides that the shipping_date will remain null (see oops, below) until the
item is shipped (no future dates allowed), or, if there is a problem (as
with getting Dell PCs shipped by the ship date), just update the
shipping_date to some other future date. Or just call it shipped_date and
only allow past dates. However one wants to do it... But in no case is a
Boolean needed. It is always possible to calculate if shipping _has_
occurred.
Oops: But now this "null" business now puts me at odds with what I wrote to
Joe Celko earlier. Looks like "null" has a business meaning in this case.
But Booleans would still be superfluous.
Bob Badour
You just changed your requirements to suit the design. That puts the cart
before the horse. You must develop your design to suit your requirements.
> Oops: But now this "null" business now puts me at odds with what I wrote
to
> Joe Celko earlier.
Yes, it does put you at odds with what you wrote earlier. You proposed
business requirements suggesting NULL means unknown and that future ship
dates mean anticipated ship dates. According to those requirements, one
would need the boolean or some other indicator to indicate that an item has
not been shipped even though the anticipated ship date has passed.
Some requirements will suggest the use of a boolean and some will not.
What's your point?
Now, if you were to suggest that 'shipped' is probably one of more than two
states in a state machine, I would tend to agree. Off the top of my head, I
might guess it has states like: ordered/created, confirmed/paid, prepared,
inspected, packaged, shipped, return authorized, return received, return
confirmed etc.
Tom Ivar Helbekkmo
> Some requirements will suggest the use of a boolean and some will not.
> What's your point?
If I may interject, I think the point of the whole discussion hinges
on the validity of the statement by Joe Celko (for whom I hold great
respect) that storing boolean data in a database is always wrong.
Lots of more or less contrived examples have been given showing cases
where booleans seem to be indicated or contra-indicated, but those are
special cases. What I'd like to see, from those of you who know more
about these things than I, is a discussion of the relative merits of
boolean attributes (true/false/null) and text encodings (yes/no/null)
in cases where either seems sufficient at first glance.
Can booleans, combined with basic logic operations and the predicate
IS UNKNOWN, be acceptable in cases where derived data is never stored,
and each data item is true, false or unknown (null)? Or are there
problems with the evaluation logic of SQL that will kick you in the
teeth when you least expect it? Should a text encoding of boolean
values be yes/no/unknown and NOT NULL? Should booleans be NOT NULL?
I've been using booleans when that fits my data model. I've never
experienced any problems with this. Looking at some schemas, I seem
to always make them NOT NULL, and usually give them a DEFAULT value,
so I may have avoided problems that would otherwise have taught me to
avoid their use.
-tih
--
Tom Ivar Helbekkmo, Senior System Administrator, EUnet Norway
www.eunet.no T: +47-22092958 M: +47-93013940 F: +47-22092901
Bob Badour
news:86y92j8...@athene.i.eunet.no...
> "Bob Badour" <bba...@golden.net> writes:
>
> > Some requirements will suggest the use of a boolean and some will not.
> > What's your point?
>
> If I may interject, I think the point of the whole discussion hinges
> on the validity of the statement by Joe Celko (for whom I hold great
> respect) that storing boolean data in a database is always wrong.
>
> Lots of more or less contrived examples have been given showing cases
> where booleans seem to be indicated or contra-indicated, but those are
> special cases. What I'd like to see, from those of you who know more
> about these things than I, is a discussion of the relative merits of
> boolean attributes (true/false/null) and text encodings (yes/no/null)
> in cases where either seems sufficient at first glance.
I'm not a big fan of null. It's definition and behaviour in SQL are
inconsistent at the very minimum and extremely harmful in practice. A
boolean is better than a text yes/no if yes and no mean the same as true and
false respectively. Concatenation doesn't really have any meaning for
yes/true and no/false, but conjunction and implication do.
People often misuse boolean just as they misuse any other type. For
instance, the boolean type has two values neither of which are male or
female and neither of which are shipped or returned and neither of which are
open or closed and neither of which are on or off etc. etc. etc.
> Can booleans, combined with basic logic operations and the predicate
> IS UNKNOWN, be acceptable in cases where derived data is never stored,
> and each data item is true, false or unknown (null)?
Boolean is a type which comprises the set of acceptable values and the
operations on those values. It makes no sense to talk about booleans
combined with logic operations. It's like talking about integers combined
with integer operations. Without the operations, the concept of integer is
meaningless.
Since NULL and IS UNKNOWN are not necessary, I suggest we just drop them and
stick to boolean.
> Or are there
> problems with the evaluation logic of SQL that will kick you in the
> teeth when you least expect it?
Well, that's true any time one attempts to use logic with SQL NULLs.
> Should a text encoding of boolean
> values be yes/no/unknown and NOT NULL?
You have not suggested any argument for using text encodings of boolean
instead of boolean. Doing so only replaces boolean operations with text
operations to no good purpose.
> Should booleans be NOT NULL?
Bluntly, all domains should be not null.
Paul
bba...@golden.net says...
> > And there would be precious few apps that would need this!
> So says you.
And I still say it.
> I have worked on applications for genetic counsellors, and they
> might disagree.
And that's fine.
Can you *_not see_* that this kind of discussion is *_completely_*
irrelevant for 99.9% (probably more) of applications?
I think that I've already mentioned that I have a degree and Masters in
genetics (and a very good friend in the Pasteur who studies nothing but
sex-determination in humans), so I've probably forgotten more than most
will ever know about genetics and intersexes and defects.
> With ever more rapid advances in medicine and in
> understanding human genetics, this sort of thing will only get more
> important.
Not for membership apps for Youth Hostel organisations or 99.99% of
apps.
> Someday, someone might have to design a data model for an application that
> accounts for chimeras as well. While rare, such people do exist.
Indeed - for genetic counsellors and medics and researchers perhaps -
for Joe Sixpack - not a chance.
> > But would call themselves "male" and look "reasonably" male and have
> > something resembling a willy and use the men's room and be able to sleep
> > in the male dorm - even if they were lacking in the willy dept., there's
> > nothing obliging people to strip off in dorms.
> You can make up whatever requirements you want to try to justify your bad
> design suggestion. Neither male nor female is true and HasYChromosome
> necessarily help you to assign dormitories.
This is becoming fruitless - do you or do you not accept that this sort
of arcane discussion about genetic abnormalities has *_IN EFFECT_* no
relevance *_WHATSOEVER_* for the vast majority of people either
designing or using applications?
> I would suggest a Dormitory domain and an AssignedDormitory attribute. That
> way, you could have as many dormitories as you need and assign them any
> number of ways.
There are male and female dorms - no more, no less.
Children under 7 may be considered either for the purposes of sleeping
(if they prefer their mothers or whatever) - which is perhaps a far more
realistic and real world scenario than the mutants you are talking
about!
However, the children's maleness or femaleness is boolean!
> > I am writing an application for the real world, not the far out
> > scenarios you are describing.
> In your real-world application, neither male nor female is true and
> HasYChromosome will not suffice for assigning dormitories.
It is and it will. If I wish to debate philosophy and/or go down the
road of bringing up bizarre sideshow cases for what is a bread and
butter simple app - then fine.
I can see the face of the manager of the organisation for which I'm
writing the app - "Well here Mr Sixpack, you have gender - as you can
see it has 15 records (what with intersexes and chimerae and
whatnot!)"...
It just ain't gonna happen.
> In any case, I
> was addressing your sweeping generality regarding meaning in the real world
> and not the specific requirements of your application, which are of course
> just as meaningless to most of the real world.
You were getting bogged down in arcana.
> > Intersexes generally resemble one or the other and are treated as such.
> What if the intersexed child protests?
It's given a smack in the mouth and told that "You're sleeping in
Mommy's room, end of story".
> > If one wanders in off the street to join a Youth Hostel Organisation, I
> > doubt if anyone's going to ask me about any history of sexual abuse.
> In that case, it might be safer to arrange sleeping arrangements some other
> way.
What arrangements? Do you know anywhere (hotel, hostel, whatever) that
would enquire as to its customers criminal sexual history - "Excuse me
sir, have you a conviction for buggering young boys?"... you're going
down the silly trail again!
> > > What does the implication function mean for gender?
> > Eh?
> Implication has meaning as a binary operation on boolean values. What
> meaning does it have for gender if gender is a boolean value?
I may be stupid, but I still don't understand what you mean here.
> > Indeed, which is why I asked in the first place.
> That wasn't what you asked in the first place--at least not the first place
> I saw. In the first place, you asked why boolean is an inappropriate domain
> for gender. You don't seem particularly willing to accept the answer to the
> question, though.
I am perfectly willing so to do! I am disputing the utility of the
justification for having anything more than a Boolean in any more than
0.001% of applications.
Paul...
--
plinehan__AT__yahoo__DOT__com
C++ Builder 5 SP1, Interbase 6.0.1.6 IBX 5.04
Paul
71062...@compuserve.com says...
> N. Wirth said it very nicely: "A good language should make
> good programming easier and bad programming harder".
So, you're a fan of Pascal (and by extension Delphi) then?
Bob Badour
>
> bba...@golden.net says...
>
> > > And there would be precious few apps that would need this!
>
> > So says you.
>
> And I still say it.
>
> > I have worked on applications for genetic counsellors, and they
> > might disagree.
>
> And that's fine.
>
> Can you *_not see_* that this kind of discussion is *_completely_*
> irrelevant for 99.9% (probably more) of applications?
All sample designs are completely irrelevant for 99.9999% of applications.
The requirements will drive the design, and all applications have different
requirements. Can you not see that?
> I think that I've already mentioned that I have a degree and Masters in
> genetics (and a very good friend in the Pasteur who studies nothing but
> sex-determination in humans), so I've probably forgotten more than most
> will ever know about genetics and intersexes and defects.
So? When did either true or false become male or female? For a guy with a
Masters degree, some of the simplest points seem to sail clear over your
head.
> > With ever more rapid advances in medicine and in
> > understanding human genetics, this sort of thing will only get more
> > important.
>
>
> Not for membership apps for Youth Hostel organisations or 99.99% of
> apps.
The requirements for Youth Hostel organisations are irrelevant for at least
99.9999% of all applications. What makes you think youth hostel dormitory
assignment is so special that the general principles governing domain choice
no longer apply to it?
> > Someday, someone might have to design a data model for an application
that
> > accounts for chimeras as well. While rare, such people do exist.
>
> Indeed - for genetic counsellors and medics and researchers perhaps -
> for Joe Sixpack - not a chance.
And for 99.9999% of application developers, the requirements of youth hostel
dormitory assignment are completely irrelevent. This newsgroup is not
comp.databases.hostels.youth
You still have not explained when or how true became either male or female.
Nor have you explained what conjunction or implication mean for gender.
You asked what is wrong with using a boolean for gender. I explained that
directly and succinctly. I should hope a Master's graduate could comprehend
such simple points.
> > > But would call themselves "male" and look "reasonably" male and have
> > > something resembling a willy and use the men's room and be able to
sleep
> > > in the male dorm - even if they were lacking in the willy dept.,
there's
> > > nothing obliging people to strip off in dorms.
>
> > You can make up whatever requirements you want to try to justify your
bad
> > design suggestion. Neither male nor female is true and HasYChromosome
> > necessarily help you to assign dormitories.
>
> This is becoming fruitless - do you or do you not accept that this sort
> of arcane discussion about genetic abnormalities has *_IN EFFECT_* no
> relevance *_WHATSOEVER_* for the vast majority of people either
> designing or using applications?
Do you accept that the requirements for a youth hostel application with
exactly two dormitories have no effect or relevance whatsoever for the vast
majority of people either designing or using applications? I have given
several reasons why a boolean for gender does not make any sense for any
application--including youth hostel dormitory assignment.
You have not addressed any of the reasons I gave--not one. When did false
become male or female? What meaning does implication have for gender? How
does a boolean gender help when the hostel expands its dormitories with
additional choices? What are the values for gender? They are not the same as
the values for boolean. What are the operations for gender? They are not the
same as the operations for boolean. In short, gender <> boolean.
Those are all reasons why boolean is a bad choice for gender, which is the
original question you asked. If you won't accept the correct answer, what
was the point in asking?
> > I would suggest a Dormitory domain and an AssignedDormitory attribute.
That
> > way, you could have as many dormitories as you need and assign them any
> > number of ways.
>
> There are male and female dorms - no more, no less.
With all due respect, this newsgroup is not
comp.databases.hostel.youth.dormitories.two
You asked why boolean is a poor choice for gender. I answered that directly
and succinctly. The values for gender are not the same as the values for
boolean, and the operations for gender are not the same as the operations
for boolean. If you want a good domain choice for gender, choose a domain
whose values include the values for gender and whose operations are the
operations that apply to gender.
If you don't want answers to your questions, don't ask them.
> Children under 7 may be considered either for the purposes of sleeping
> (if they prefer their mothers or whatever) - which is perhaps a far more
> realistic and real world scenario than the mutants you are talking
> about!
Your one application does not define the universe of discourse in a theory
newsgroup. Sorry.
> However, the children's maleness or femaleness is boolean!
If that is the case, please explain what the implication operation means for
gender. When and how did true become male or female?
> > > I am writing an application for the real world, not the far out
> > > scenarios you are describing.
>
> > In your real-world application, neither male nor female is true and
> > HasYChromosome will not suffice for assigning dormitories.
>
> It is and it will.
When and how did true become male or female? How does HasYChromosome help
for dormitory assignment when some females may have Y chromosomes and some
males may not?
> If I wish to debate philosophy and/or go down the
> road of bringing up bizarre sideshow cases for what is a bread and
> butter simple app - then fine.
I wish to discuss theory--as in comp.databases.theory
Values and operations define domains. The values for gender and the values
for boolean are different. The operations for gender and the operations for
boolean are different. Gender and boolean are different. The differences
make boolean an inappropriate choice for gender.
You asked, and I answered. The correct answer doesn't change just because it
wasn't the answer you expected. Sheesh!
> I can see the face of the manager of the organisation for which I'm
> writing the app - "Well here Mr Sixpack, you have gender - as you can
> see it has 15 records (what with intersexes and chimerae and
> whatnot!)"...
>
> It just ain't gonna happen.
Why would a domain have records? A domain has values and operations. The
boolean domain has a value called true, a value called false and no value
called male. The boolean domain has an operation called implication, among
other operations, and gender has no such operation.
Your application may at present only care about two gender values: male and
female. The fact that boolean also has two values does not make true male
and does not make boolean gender.
You asked why boolean is a poor design choice for gender, and I answered:
different values and different operations. I cannot help it if you are not
capable to comprehend or not willing to accept the answer. The correct
answer doesn't change to suit your incapacity or your inflexibility.
> > In any case, I
> > was addressing your sweeping generality regarding meaning in the real
world
> > and not the specific requirements of your application, which are of
course
> > just as meaningless to most of the real world.
>
> You were getting bogged down in arcana.
I am not the one who is fixated on a single application, who cannot
comprehend that complete difference in the defining attributes of domains
makes domains different, and who thinks his application has theoretical
importance beyond all other applications. You refuse to look at anything but
arcana.
> > > If one wanders in off the street to join a Youth Hostel Organisation,
I
> > > doubt if anyone's going to ask me about any history of sexual abuse.
>
> > In that case, it might be safer to arrange sleeping arrangements some
other
> > way.
>
> What arrangements? Do you know anywhere (hotel, hostel, whatever) that
> would enquire as to its customers criminal sexual history - "Excuse me
> sir, have you a conviction for buggering young boys?"... you're going
> down the silly trail again!
Get a sense of humour. Buy one if you have to.
> > > > What does the implication function mean for gender?
>
> > > Eh?
>
> > Implication has meaning as a binary operation on boolean values. What
> > meaning does it have for gender if gender is a boolean value?
>
> I may be stupid, but I still don't understand what you mean here.
You contend that boolean is the appropriate domain for gender. A domain
defines a set of values and the operations on those values. Boolean does not
have male nor female in its set of values, and boolean defines operations
(implication among them) that are totally inappropriate for gender.
You asked why boolean is an inappropriate choice for the domain for gender.
Boolean defines the wrong set of values for gender and the wrong operations
for gender. Since values and operations are the defining characteristics of
domains, it would seem pretty clear to me that different values and
different operations make boolean a poor choice for gender.
> > > Indeed, which is why I asked in the first place.
>
> > That wasn't what you asked in the first place--at least not the first
place
> > I saw. In the first place, you asked why boolean is an inappropriate
domain
> > for gender. You don't seem particularly willing to accept the answer to
the
> > question, though.
>
> I am perfectly willing so to do!
When do you intend to demonstrate this alleged willingness?
> I am disputing the utility of the
> justification for having anything more than a Boolean in any more than
> 0.001% of applications.
You dispute the need for any other type than boolean for 99.999% of
applications?!? That's an extraordinary statement. You are contending that
only 0.001% of applications have any use for character strings, numbers,
colours, dates, times, etc. etc. etc.
Steve Kass
to make sense for every entity represented by that type.
What does the concatenation operator mean for City?
True did not become male or female any more than 17
became an age (never again to be an integer) when
someone used an integer for an age in a schema.
The observation that a dog is a mammal does not make
mammals into dogs.
As for implication, even though there is no requirement
that it make sense for every boolean entity, one might
want to test the theory that an child born within 30
seconds of a Male is not a Male:
not exists (
select * from Children C1, Children C2
where C2.Birth between C1.Birth and dateadd(second,30,C1.Birth)
and not (C1.HasYChromosome --> not C2.HasYChromosome)
)
SK
GoranG
wrote:
>>> I do agree that storing a ship_date (shipping date) makes data more
>meaningful and is a good thing in 91,7%, or so, cases. <<
>
>Accounting will not work without it! This example is a 100%
>requirement.
... of a good design (logical) of an accounting system. But accounting
does not represent 100% of all possible business models, does it?
As a side note for accounting: You must agree that somewhere you will
have to stop (one might say that accounting requires delivery date as
well, and some other information).
Are you simply arguing that you don't ever need to stop at boolean
value (as opposed to some supported type)? Or that it is bad to stop
at such value (as in gather more data, not less)?
Certain accounting business model might have a following rule for
IsShipped (boolean) property:
- Shipping is confirmed by authority A, where authority A has it's own
rules, procedures and does not want to share any data with us except
confirmation. Item is considered shipped if authority A confirms it,
unless an in-house officer establishes that authority B also needs to
confirm, unless the shipped item falls within certain category list
which is reviewed every second quarter of a financial year.
So at the end I decide (by comparing costs) to model IsShipped
property as boolean and keep all that hype which will change with the
next month's law out of my model. At the same time I am consciously
avoiding using an absence of a natural property ship_date since
effective business rule for determining if shipment occurred certainly
does not correspond to it and such artificial functional dependency
could only mislead my programmers and/or incur data loss (in this
example!).
This is reality. <g>
>>> However the principle is not ok ... If my model only cares about
>Female property for an entity, and if this property has domain (True,
>False) in my model's semantics ... <<
>This is a bad data model; clearly "female" is a value of an attribute;
>the domain is "gender".
At what level? Logical - yes. Physical - must I really model it as
such if my business really does not care about it? (context of my
models semantics determine domains, not a general consensus on 'true'
meaning of things).
Furthermore we are discussing ability to do something proscribed by
standard, not general guidelines for good design.
>>> And sure - one can always store boolean values as expression: (some
>property = some value), but isn't this complexity overhead in general?
><<
>
>That is not complexity; that is reality <g>! A Boolean is too general
>to carry much meaning.
Any type is inappropriate to carry meaning out of its own domain. <g>
Boolean's only difference is that its domain is so small that it can
easily be included in same state transition coding scheme or other
types by exploiting special values.
Anith Sen
>> Just because an operation exists for a type doesn't mean it has to make
sense for every entity represented by that type. <<
Well, define your own type, then.
I think you misinterpreted Bob's point. The Boolean type has only two values
(true, false) and a set of operators that apply to them. If your business
model requires values other than true or false, then you need to define
another domain with relevant values & associated operations those values
support and use this domain in your logical model. If gender in your
business model means, 'male' and 'female' (note, these are character
strings), then create a domain along the lines of :
TYPE gender POSSREP ( CHAR );
OPERATOR (<>, = );
You can define your own operators based on your requirements as well like:
OPERATOR xyz (g1 CHAR, g2 CHAR) RETURNS CHAR
RETURN (IF g1 = g2 THEN g1 ELSE '') ;
END OPERATOR;
Types allow the user to meaningfully compare the values in a logical model
against other values in the same domain. Also note that the operators, being
type-defined, will disallow other meaningless comparisons like
concatenation, >=, < etc. Thus the DBMS will know exactly which expressions
are legal and the type of the result for each such legal expression. It can
preserve domain integrity efficiently thereby, knowing which assignments and
comparisons are legal as well.
Simply trying to create a comparable logic in a language (case in point,
SQL) which does not even support the basic concept of domains does not hold
water in this case.
--
- Anith
(Please respond only to newsgroups)
Alfredo Novoa
> There were a few reason for not having it in SQL-92.
>
> To be a datatype in SQL, you have to be NULL-able. If you allow a
> LOGICAL datatype, then it has to be TRUE, FALSE, UNKNOWN and be
> NULL-able! But NULL does not work with AND, OR and NOT. Then there
> is the problem that an empty scalar subquery is cast as a NULL. The
> CHECK() constraint in the DDL accepts predicatres that test UNKNOWN,
> while ON and WHERE in the DML do not. It gets to be a mess really
> fast.
I am reading the SQL 2003 working drafts, and I am surprised to see
that a boolean type was finally added.
Regards
Alfredo
Troels Arvin
> I am reading the SQL 2003 working drafts, and I am surprised to see
> that a boolean type was finally added.
The boolean type has been in the standard for a while, at least since
SQL:1999. But it isn't a _core_ SQL:1999 requirement.
Has that changed in SQL:2003?
/Troels
Steve Kass
Either you misunderstood me, or I misunderstood Bob. I thought
he was saying boolean should _not_ be used for a column representing
gender as the value of "is male". I thought it was fine to use a
boolean for that. So I'm not sure why you suggest I define a type,
since Bob is the one who doesn't like the existing type, not me.
Bob used as an argument against a boolean table column that
implication didn't make sense for "is male". Whether it does or
not, it sounds like you are agreeing with me and pointing out
that SQL just doesn't have the capability to specify which
operators are allowed with which types.
Steve
--CELKO--
since SQL:1999. But it isn't a _core_ SQL:1999 requirement. <<
To quote from SQL-99 COMPLETELY, REALLY by Gulutzan & Pelzer:
"Warning: by saying that UNKNOWN and NULL are both to be used
interchangably to mean the same thing, one is saying that "I don't
know" and "I know the data is missing" are the same thing. The
drafters of the SQL Standard apparently forgot the distinction, and
they have ben justly critisized for this error."
The foundations of SQL asserted that: (1) UNKNOWN and NULL are
totally different values in totally domains (2) All datatypes can
support NULLs (3) NULLs have predictable values, which include
propagation. Look at the basic 3VL:
TRUE OR UNKNOWN = TRUE
TRUE OR NULL = NULL = UNKNOWN -- assuming propagation of null!!
Well, there goes the foundations!!
>> Has that changed in SQL:2003? <<
We can only pray...
--CELKO--
contributions to the above threads are "good" as opposed to "bad"
(unreasonable, misleading, containing bad advice) ... If I want to say
that your contribution is good I'd put a "true". If I am in doubts or
have mixed feelings, I don't want to pronounce, I won't insert
anything. ... Voila: a natural usage of boolean datatype, *and* there
are no NULLs in the table, and no NULLs are ever needed in this case
... <<
You never worked as a statistician! You need a subjective preference
scale that has either 5 or 7 steps ("walks on water" to "sucks rocks")
in the scale for this kind of task. More values in the scale and the
results are not reproducible; fewer values and the test instrument is
not usable :)
Alfredo Novoa
> On Fri, 11 Apr 2003 07:34:50 -0700, Alfredo Novoa wrote:
>
> > I am reading the SQL 2003 working drafts, and I am surprised to see
> > that a boolean type was finally added.
>
> The boolean type has been in the standard for a while, at least since
> SQL:1999. But it isn't a _core_ SQL:1999 requirement.
Thanks, I have not readen SQL:1999 specs.
> Has that changed in SQL:2003?
No, it is still out of the core. But many vendors have implemented it.
Regards
Alfredo
Troels Arvin
> many vendors have implemented it.
"Many"? - I have only found it in PostgreSQL.
/Troels
Peter Gulutzan
And Informix, and SAP DB, and some minor vendors.
Peter Koch Larsen
Well.... SQL has many faults, one of them being the value of having a
NULL datatype. While I tend to agree that nulls in basetables are of
little or no value, I do see the NULL value as a reasonable way to
support outer joins.
This terrible of treating null-values with propagation is just
incoherent, however. Who ever invented that? While meaningful for e.g.
arithmetic values (null + x is clearly null, and it seems reasonable
to treat null*x = null even though this is incoherent if x = 0), this
is just silly for booleans and possibly also for some userdefined
datatypes. Why does SQL not use three-valued logic?
Kind regards
Peter
--CELKO--
a
NULL datatype. <<
It is not a datatype! It is not a data value! It is a marker for a
missing value. These differences are important.
>> While I tend to agree that nulls in basetables are of little or no
value, I do see the NULL value as a reasonable way to support outer
joins. <<
While I want to have DEFAULT or NOT NULL whenever possible, NULLs can
be useful in tables. My favorite is as an "eternity symbol" in
durations:
CREATE TABLE Foobar
(...
start_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
end_date DATE, -- null means on-going event
CHECK(start_date <= end_date),
...);
>> This terrible of treating null-values with propagation is just
incoherent, however. Who ever invented that? <<
Dr. Codd. He later had two nulls -- missing value, and missing
attribute
>> While meaningful for e.g. arithmetic values (null + x is clearly
null, and it seems reasonable to treat null*x = null even though this
is incoherent if x = 0), <<
Try (null/0); a lot of SQL products got it wrong. You are assuming
that a NULL is a value of a numeric datatype, so that the laws of
arithemetic apply. It is not a numeric; it has no datatype at all.
>> Why does SQL not use three-valued logic? <<
Dr. Codd and the NULLs required it.
--CELKO--
An empty scalar query converts to a NULL in Standard SQL, so you have
to watch the usage.
Another problem with BOOLEAN datatypes is that they apply to
propositions; A table is a collection of facts, if you believe Chris
Date. Opps, we are now working at two different levels an get
allthose self-referencing problems.
Costin Cozianu
>>>Well.... SQL has many faults, one of them being the value of having
>
> a
> NULL datatype. <<
>
> It is not a datatype! It is not a data value! It is a marker for a
> missing value. These differences are important.
>
>
>>>While I tend to agree that nulls in basetables are of little or no
>
> value, I do see the NULL value as a reasonable way to support outer
> joins. <<
>
> While I want to have DEFAULT or NOT NULL whenever possible, NULLs can
> be useful in tables. My favorite is as an "eternity symbol" in
> durations:
>
> CREATE TABLE Foobar
> (...
> start_date DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,
> end_date DATE, -- null means on-going event
> CHECK(start_date <= end_date),
> ...);
>
Actually here you are representing a sum type.
type extendeDate = PastEternity | JustDate of date | FutureEternity
of course this is in ML (you can do the same in Haskell, Clean and a few
other modern languages).
but you "translated" it in a contorted and unsafe way in SQL.
>
>>>This terrible of treating null-values with propagation is just
>
> incoherent, however. Who ever invented that? <<
>
> Dr. Codd. He later had two nulls -- missing value, and missing
> attribute
>
>
>>>While meaningful for e.g. arithmetic values (null + x is clearly
>
> null, and it seems reasonable to treat null*x = null even though this
> is incoherent if x = 0), <<
>
> Try (null/0); a lot of SQL products got it wrong. You are assuming
> that a NULL is a value of a numeric datatype, so that the laws of
> arithemetic apply. It is not a numeric; it has no datatype at all.
>
>
>>>Why does SQL not use three-valued logic? <<
>
>
> Dr. Codd and the NULLs required it.
Dr. Codd required that a relation is a set of tuples.
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.
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.
Mandating that users abide by an ugly three valued logic for all their
needs is really a bad solution and should be deprecated.
Peter Koch Larsen
> --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:
1) Use a NULLABLE type. This could be an extension like the sum-type
mentioned (i have not read that thread yet so i can not comment). I
see no problems with that approach.
2) Use a DEFAULT value. This could be feasible in some situations, but
in many situations it would not. The most obvious example would be if
the field in question is boolean. Which default could you possible
use?
3) Use a marker that existed independently of the field. This approach
has so many flaws that I believe it to be infeasible. For one thing,
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
Bruce Rennie
> Costin Cozianu <c_co...@hotmail.com> wrote in message news:<b7ncgr$2odsj$1...@ID-152540.news.dfncis.de>...
> > --CELKO-- wrote:
>
> [large snip]
>
> >
> > 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.
In fact - IMPOSSIBLE. Boolean algebras require either 2 or an integer
power of 2 number of values in the domain. Check any good
combinatorics text for how this works. So at a minimum you will have
True or False ( 2 distinct values )
or you could have
True A B False ( 4 distinct values ) or 8, 16, etc
where both A and B are part way between True and False.
This leads to the correct logic tables.
Since three valued logic is not Boolean ( there are a number of
different ways the logic operations can be written ( for 3VL-AND and
3VL-OR and 3VL-NOT )), you have to decide on the particular operations
that you will allow and how the results will be calculated. Therefore,
the normal Boolean operations of AND and OR and NOT cannot and do not
work with three value domains.
Allowing another value in the Boolean (2VL) domain forces it to no
longer be Boolean. Problems arise. For further research, look at the
Russian TERNARY computer from the 1950's. This was not a Boolean logic
based machine.
> >
>
> 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:
If the value is missing, then provide a way in the design of the
database that allows you NOT to store information without resorting to
the use of NULLS. An appropriate redesign/rethink of the questions
being asked of the DBMS on the database will give rise to sensible
answers. Too many times I've been required to provide answers to the
wrong questions - so - teach the questioners to ask the right
questions - not always easy, but doable. It allows correct information
to be given instead of wrong/partially correct that is generally
given now (statement is stated this way deliberately - think carefully
the implications).
>
> 1) Use a NULLABLE type. This could be an extension like the sum-type
> mentioned (i have not read that thread yet so i can not comment). I
> see no problems with that approach.
> 2) Use a DEFAULT value. This could be feasible in some situations, but
> in many situations it would not. The most obvious example would be if
> the field in question is boolean. Which default could you possible
> use?
> 3) Use a marker that existed independently of the field. This approach
> has so many flaws that I believe it to be infeasible. For one thing,
> 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
regards
--
Bruce Rennie ( from God's Own Country Downunder )
Disciple of Jesus Christ in Training
The Cross of Jesus Christ - Salvation for all men.
Song of Solomon ( Song of Songs ) - The greatest Love Story Ever
and a story for our times.
Be a GOD Chaser.
Peter Koch Larsen
> p...@mailme.dk (Peter Koch Larsen) wrote in message news:<61c84197.03041...@posting.google.com>...
> > Costin Cozianu <c_co...@hotmail.com> wrote in message news:<b7ncgr$2odsj$1...@ID-152540.news.dfncis.de>...
> > > --CELKO-- wrote:
> >
> > [large snip]
> >
> [Snipped]
> > >
> > > 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.
>
> In fact - IMPOSSIBLE. Boolean algebras require either 2 or an integer
> power of 2 number of values in the domain. Check any good
> combinatorics text for how this works. So at a minimum you will have
>
> True or False ( 2 distinct values )
>
> or you could have
>
> True A B False ( 4 distinct values ) or 8, 16, etc
>
> where both A and B are part way between True and False.
>
> This leads to the correct logic tables.
A "nullable" boolean is not a boolean, of course. But using three
valued logic is never the less feasible.
>
> Since three valued logic is not Boolean ( there are a number of
> different ways the logic operations can be written ( for 3VL-AND and
> 3VL-OR and 3VL-NOT )), you have to decide on the particular operations
> that you will allow and how the results will be calculated. Therefore,
> the normal Boolean operations of AND and OR and NOT cannot and do not
> work with three value domains.
I am not sure I understand you.
>
> Allowing another value in the Boolean (2VL) domain forces it to no
> longer be Boolean. Problems arise. For further research, look at the
> Russian TERNARY computer from the 1950's. This was not a Boolean logic
> based machine.
I do agree it's not boolean anymore but fail to see any problems.
Reverting to plain old C++, here is a class that implements three
valued logic (partly pseudo-code, but I'm sure you will get the idea):
class nullable_boolean
{
boolean isnull;
boolean value;
public:
nullable_boolean(): isnull(true) {}
nullable_boolean(boolean val): isnull(false),value(val) {}
operator boolean() { return !isnull && val; }
operator or(nullable_boolean rhs)
{
if (rhs.isnull) return myself;
if (rhs) return true;
return value;
}
};
Three-valued logic implemented in a handfull of lines - probably
Haskell could do it in much simpler way.
>
> > >
> >
> > 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:
>
> If the value is missing, then provide a way in the design of the
> database that allows you NOT to store information without resorting to
> the use of NULLS. An appropriate redesign/rethink of the questions
> being asked of the DBMS on the database will give rise to sensible
> answers. Too many times I've been required to provide answers to the
> wrong questions - so - teach the questioners to ask the right
> questions - not always easy, but doable. It allows correct information
> to be given instead of wrong/partially correct that is generally
> given now (statement is stated this way deliberately - think carefully
> the implications).
So you argue that the outer join is not necesarry? If you are right,
the discussion is over of course, but my premise was exactly that the
outer join is here to stay.
[snip]
Kind, albeit ateistic regards
Peter
Damjan S. Vujnovic
> > different ways the logic operations can be written ( for 3VL-AND and
> > 3VL-OR and 3VL-NOT )), you have to decide on the particular operations
> > that you will allow and how the results will be calculated. Therefore,
> > the normal Boolean operations of AND and OR and NOT cannot and do not
> > work with three value domains.
>
> I am not sure I understand you.
You cannot define operators AND and OR on a 3-element set in such a way that
all axioms of Boolean algebra are satisfied. Try to fill-out those two
tables in such a way that axioms hold:
+ T F N
T ? ? ?
F ? ? ?
N ? ? ?
* T F N
T ? ? ?
F ? ? ?
N ? ? ?
T=True F=False N=Null(or whatever) +=OR *=AND
Hint: The problem will be the existence of the inverse element...
--
Regards,
Damjan S. Vujnovic
University of Belgrade
School of Electrical Engineering
Department of Computer Engineering & Informatics
Belgrade, Serbia
http://galeb.etf.bg.ac.yu/~damjan/
Peter Koch Larsen
"Damjan S. Vujnovic" <dam...@galeb.etf.bg.ac.yu> skrev i en meddelelse
news:b85ldc$h0c$1...@news.etf.bg.ac.yu...
> > > Since three valued logic is not Boolean ( there are a number of
> > > different ways the logic operations can be written ( for 3VL-AND and
> > > 3VL-OR and 3VL-NOT )), you have to decide on the particular operations
> > > that you will allow and how the results will be calculated. Therefore,
> > > the normal Boolean operations of AND and OR and NOT cannot and do not
> > > work with three value domains.
> >
> > I am not sure I understand you.
>
> You cannot define operators AND and OR on a 3-element set in such a way
that
> all axioms of Boolean algebra are satisfied. Try to fill-out those two
> tables in such a way that axioms hold:
With the risk of sounding very uneducated let me ask which axioms you are
referring to. Also, I would like to ask why such axioms should hold
considering we are not discussing boolean algebra but an extension to it. I
would be happy if only all axioms would hold whenever no nulls were
involved.
>
> + T F N
> T ? ? ?
> F ? ? ?
> N ? ? ?
>
+ T F N
T T T T
F T F N
N T N F
> * T F N
> T ? ? ?
> F ? ? ?
> N ? ? ?
>
* T F N
T T F N
F F F F
N N F N
~ T F N
F T N
>
> T=True F=False N=Null(or whatever) +=OR *=AND
~= "NOT"
>
Very naive, perhaps ;-)
> Hint: The problem will be the existence of the inverse element...
Give me a little more help, please.
Kind regards
Peter Koch Larsen
andrewst
Originally posted by Peter Koch Larsen
(X or Y) is equivalent to !(!X and !Y) (e.g. "big OR ugly" is same as
"not(small AND beautiful)")
because if X and Y are NULL then
(X or Y) = (NULL or NULL) = FALSE (from your OR table, SQL would say
NULL)
But (X or Y) is equivalent to !(!X and !Y), i.e. !(!NULL and !NULL)
= !(NULL and NULL) (from your NOT table)
= !NULL (from your AND table)
= NULL (from your NOT table)
So now you have FALSE = (NULL or NULL) = NULL
And if NULL = FALSE then !NULL = TRUE, and so NULL is also TRUE (since
!NULL = NULL)...
--
Posted via http://dbforums.com
--CELKO--
way that all axioms of Boolean algebra are satisfied. <<
I think I am missing your point.
There several consistent multi-valued logic system. I am in the
middle of moving my office to a new building this weekend, but I have
a list of axioms for a dozen or so n-valued logics. Some include the
traditional Boolean axioms and some do not.
Bruce Rennie
> "Damjan S. Vujnovic" <dam...@galeb.etf.bg.ac.yu> skrev i en meddelelse
> news:b85ldc$h0c$1...@news.etf.bg.ac.yu...
> > > > Since three valued logic is not Boolean ( there are a number of
> > > > different ways the logic operations can be written ( for 3VL-AND and
> > > > 3VL-OR and 3VL-NOT )), you have to decide on the particular operations
> > > > that you will allow and how the results will be calculated. Therefore,
> > > > the normal Boolean operations of AND and OR and NOT cannot and do not
> > > > work with three value domains.
> > >
> > > I am not sure I understand you.
> >
> > You cannot define operators AND and OR on a 3-element set in such a way
> that
> > all axioms of Boolean algebra are satisfied. Try to fill-out those two
> > tables in such a way that axioms hold:
>
> With the risk of sounding very uneducated let me ask which axioms you are
> referring to. Also, I would like to ask why such axioms should hold
> considering we are not discussing boolean algebra but an extension to it. I
> would be happy if only all axioms would hold whenever no nulls were
> involved.
Firstly:
Commutative Laws, Distributive Laws, Identity Laws, Complement Laws
Check any text on the subject for details.
Secondly:
This is not an extension to boolean algebra. Think of it like talking
about chairs in one case (boolean) and grasshoppers in the other. The
only allowable entension to 2VL (Boolean) that you can logically have
is to increase the number of elements as an integer power of 2.
>
> >
> > + T F N
> > T ? ? ?
> > F ? ? ?
> > N ? ? ?
> >
> + T F N
> T T T T
> F T F N
> N T N F
you can also have
+ T F N
T T T T
F T F F
N T F N
This is just as valid as the choice you made so which is correct. A
similar thing can occur with * and ~. Many years ago now I looked at
ternary based computing systems and finally realized that you could
not do boolean logic with them. A completely different system would
have to be developed.
>
> > * T F N
> > T ? ? ?
> > F ? ? ?
> > N ? ? ?
> >
> * T F N
> T T F N
> F F F F
> N N F N
>
> ~ T F N
> F T N
> >
> > T=True F=False N=Null(or whatever) +=OR *=AND
> ~= "NOT"
> >
> Very naive, perhaps ;-)
>
> > Hint: The problem will be the existence of the inverse element...
> Give me a little more help, please.
>
> Kind regards
> Peter Koch Larsen
Peter,
I don't know what you background is but I would seriously suggest that
you get some engineering texts on switching theory, logic design and
try to understand the fundementals. Then look at predicate theory as
the next step.
Because it is "so easy" these days to "program", that those getting
into it are not being encouraged to learn some of the fundementals.
Compare with say car mechanics, it is possible to learn how to fix a
car by doing it as a hobby but I know that for myself I get the best
trained mechanic to work on my car - because he knows all the
fundemantals as well as the rest. By the way, my mechanic is the best
I ever seen and I travel to the next town to get to him.
What I'm saying is that it's easy these days to get some program
working but is it doing the job as it is supposed to and is it doing
it properly. The same with databases etc.
Costin Cozianu
Any formalism is as good as the quality of the solutions it brings to a
targeted domain. It's true that for logic circuits you probably need to
have a proper boolean algebra.
For the purpose of constructing type theory, which has its importance
in, it has been observed that for example Tertium Non Datur ( a \/ (!a)
= 1 ) is unnecessary or even harmful (it leads to contradictory proofs),
therefore it is not accepted.
Therefore it is true that you cannot construct boolean algebras with 3
elements, but you can construct any damn logic you please if you don't
make that a boolean algebra (i.e. drop the existence of complements and
consequently you reformulate the Tertium Non Datur or drop it altogether).
Of course, then we have to discuss the merits of the new formalism.
Given the fact that a large part of modern mathematics has done
beautfully without tertium non datur, I don't see why database users
cannot be given the benefit of a doubt that they can work in a
multi-valued logic not based on boolean algebra.
All I care for is to have a lattice with :
1) bounded below: There exists an element 0, such that a ? 0 = a for
all a in A.
2) bounded above: There exists an element 1, such that a ? 1 = a for all
a in A.
3) distributive law: For all a, b, c in A, (a ? b) ? c = (a ? c) ? (b ? c).
but without the reverse element, and without Tertium Non Datur.
4) existence of complements: For every a in A there exists an element 柑
in A such that a ? 柑 = 1 and a ? 柑 = 0.
Indeed, all the little fuzzy logic(s) I've been taught, doesn't support
number 4 at all, and number 4 would have absolutely no value for the
domains for which fuzzy logic is necessary.
Then we have to analyze the merits or demerits of each formalism, if you
want to claim that fuzzy logic has no merits because it doesn't support
number 4, you'd be way off the charts :)
So, I'm all for formalisms and for mathematics in software, but the fact
that something is a specific formalism or something else is a different
formalisms, even a less powerful (weaker) formalisms, doesn't say much.
To make a complete argument you have to discuss the value of the
formalism with regards to a particular domain of application.
If you can't apply Field theory to a problem you have to see what you
can do with Anneaux (or how the heck they are called in English ??), if
you can't have a boolean algebra you may still get useful results just
with lattice theory.
So why do you think a three valued logic (or indeed a logic on the
continuous [0,1]) is that bad for database management so that you can
dismiss it out of hand ?
Why do you think it makes any sense at all to have a boolean algebra
with 2^N elements, let's take the easiest case 4, when I don't see for
the life of me how you can map the algebraic rules to semantics
understood by users and programmers ?
best regards,
Costin Cozianu
Bruce Rennie
[lots of stuff snipped...]
>
> Any formalism is as good as the quality of the solutions it brings to a
> targeted domain. It's true that for logic circuits you probably need to
> have a proper boolean algebra.
Probably? For the kinds of circuits (technology) that are built today,
I would say essential. That of course doesn't mean that other
developments either past, present or future won't or can't bring
changes. Analog computers are still being used today in various areas
of research - however, the mathematical theory on which they are based
is sound and as far as I know complete and logical.
>
> For the purpose of constructing type theory, which has its importance
> in, it has been observed that for example Tertium Non Datur ( a \/ (!a)
> = 1 ) is unnecessary or even harmful (it leads to contradictory proofs),
> therefore it is not accepted.
>
We are dealing here with Boolean values and adding something to them.
If this added something contradicts the rules of the algebra (axioms)
then it can't be added without causing problems and misunderstandings.
> Therefore it is true that you cannot construct boolean algebras with 3
> elements, but you can construct any damn logic you please if you don't
> make that a boolean algebra (i.e. drop the existence of complements and
> consequently you reformulate the Tertium Non Datur or drop it altogether).
>
As long as it is complete and not giving rise to contradictory
functions, proofs, etc., then you can build any n-valued system you
want. But, it must be very clear what the rules (axioms) and elements
of the domain in question are. It would also be a good idea not to
make analogs with other systems by which misunderstandings can arise.
I, myself, many years ago looked at designing a 3-value system with
its appropriate operations - I decided against it after sometime
because I could not get all the inconsistancies out of it (for the
purposes I wanted it for at the time)
> Of course, then we have to discuss the merits of the new formalism.
> Given the fact that a large part of modern mathematics has done
> beautfully without tertium non datur, I don't see why database users
> cannot be given the benefit of a doubt that they can work in a
> multi-valued logic not based on boolean algebra.
>
Only give them a chance first, make sure the theory on which the
database management system is based is at least non-contradictory and
that the questions they ask can be shown to be either answerable
correctly or are nonsensical in the first place. My experience has
been that most "users" of databases have to be taught or trained how
to learn to ask the "right" questions.
So if the theory on which you are designing is solidly based then okay
- but if is not then IMHO you are barking up the wrong tree.
> All I care for is to have a lattice with :
>
> 1) bounded below: There exists an element 0, such that a ? 0 = a for
> all a in A.
> 2) bounded above: There exists an element 1, such that a ? 1 = a for all
> a in A.
> 3) distributive law: For all a, b, c in A, (a ? b) ? c = (a ? c) ? (b ? c).
>
> but without the reverse element, and without Tertium Non Datur.
>
> 4) existence of complements: For every a in A there exists an element ¬a
> in A such that a ? ¬a = 1 and a ? ¬a = 0.
>
Not a problem, but don't forget the commutative laws. And be very
claer about your mapping functions, otherwise you will end up with
contradictions.
>
> Indeed, all the little fuzzy logic(s) I've been taught, doesn't support
> number 4 at all, and number 4 would have absolutely no value for the
> domains for which fuzzy logic is necessary.
>
But are they applicable to the databases that people design and use,
such that correct answers can be obtained (relatively easily). They
have a place - but is it here. Too many times I have come across
people believing the answers obtained from databases (because thay
think everything is correct) when the answers they have obtained on
investigation have been shown to be "up the creek". Educating them is
the hardest part.
> Then we have to analyze the merits or demerits of each formalism, if you
> want to claim that fuzzy logic has no merits because it doesn't support
> number 4, you'd be way off the charts :)
>
> So, I'm all for formalisms and for mathematics in software, but the fact
> that something is a specific formalism or something else is a different
> formalisms, even a less powerful (weaker) formalisms, doesn't say much.
> To make a complete argument you have to discuss the value of the
> formalism with regards to a particular domain of application.
>
> If you can't apply Field theory to a problem you have to see what you
> can do with Anneaux (or how the heck they are called in English ??), if
> you can't have a boolean algebra you may still get useful results just
> with lattice theory.
>
> So why do you think a three valued logic (or indeed a logic on the
> continuous [0,1]) is that bad for database management so that you can
> dismiss it out of hand ?
Show the relevant developed theory that can be used to put it into
useful practise then you can ask the above question.
>
> Why do you think it makes any sense at all to have a boolean algebra
> with 2^N elements, let's take the easiest case 4, when I don't see for
> the life of me how you can map the algebraic rules to semantics
> understood by users and programmers ?
The vast majority of cases only needs the simplest algrabra of two
elements. My point regarding 2^N elements is that for it to be
considered a boolean algebra this is one of the requirements not that
it would be necessarily useful. The actual mapping funxctions for the
truth tables are quite simple and the axioms don't changes - all the
rules remain the same. I just might try teaching it to my youngest son
to see how he handles it all. My perspective is that most people
should be able to pick it up easily enough - programmers should find
it a breeze.
>
>
> best regards,
> Costin Cozianu
Bruce Rennie
Such as it may be. But if they don't follow the axioms for Boolean
algebra, then they are not Boolean algebras. This is a discussion
about Booleans.
If you wish to post your various n-valued algebras, please do so - it
will then give opportunity for them to be vetted by the community at
large.