Re: Multiplicity, Change and MV

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:p461g.61678$VV4.1151995_at_ursa-nb00s0.nbnet.nb.ca...
> x wrote:
>
> > "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
> > news:tx51g.61657$VV4.1151645_at_ursa-nb00s0.nbnet.nb.ca...
> >
> >>x wrote:
> >
> >>>There is nothing bad about nulls.
> >
> >>I suggest you check out the various _Writings..._ books by Chris Date.
> >>The flaws in NULL and NVL for N > 2 have been well-argued.
> >
> > They have been argued in prose. I prefer mathematics.
>
> SUM(A) + SUM(B) = SUM(A+B)
>
> unless either A or B can contain NULL. If you think none of the
> arguments are mathematical, I suggest you re-read them.

OK.
Define A, B, SUM and NULL.
I don't want to contradict you. I don't want you to hurry. When you have a complete example, post it if you are willing to make the effort.
I have not thought hard enough about it, but I suspect Codd had.

> > I see nothing wrong using a boolean algebra with more than 2 values.

> For what purpose, though? I see lots of things wrong with basing data
> management systems on these logics.

An example of boolean algebra is the algebra of sets.

> > Actually using only 2 values feels like using machine code. :-)
> > I see nothing wrong using a boolean algebra with uncountable many
values.
> > This in theory. I practice things may differ.
>
> Again, the purpose determines the utility. I recall examples by Codd
> that make heavy use of graph theory; although, the RM does not.

> If you think relational proponents reject mathematics, you are a fool.

I think some relational proponents don't know enough mathematics.

> >>>Only the SQL style null is bad.
> >>>You can choose if you prefer to use relations with nulls or sets of
> >>>relations.
> >
> >
> >>Unfortunately, if your DMBS has to allow for NULL, it will generally not
> >>function as well as one that does not. Even if the DBMS implementation
> >>detects all cases without NULL for optimization purposes, the DBMS will
> >>require more executable code and have more branches of execution. As a
> >>general rule, these properties will translate into slower code (ie. more
> >>page faults) and buggier code (ie. less complete coverage during
testing).
> >
> > Write once, debug a lifetime, die. :-)
> > In theory a DBMS will not have bugs. :-)
>
> Actually, in theory a DBMS will have bugs. Every human artifact has
> flaws. The important things to consider are failure modes, ease of
> detection, and chance of recovery.

> Even if one uses correctness proofs for every piece of code, humans have
> been known to create flawed proofs.

> Human failure drives many data management principles like the relational
> prohibition against subversion.

I was joking of course.
My opinion is that mathematics is experimental. I have read this somewhere and I agree. Received on Tue Apr 18 2006 - 16:00:17 CEST