Re: Multiplicity, Change and MV

From: x <x_at_not-exists.org>
Date: Wed, 19 Apr 2006 09:38:20 +0300
Message-ID: <e24lr8$7c3$1_at_emma.aioe.org>


"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:gQ71g.61734$VV4.1152974_at_ursa-nb00s0.nbnet.nb.ca...
> x wrote:
> > "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.

>

> No thank you. I have already explained this one multiple times online.
> Perhaps you can find my prior explanations using Google Groups.
>

> Otherwise, I will leave it as an exercise for the reader. If you want a
> starting place for the definition, I suggest Codd's RM/V2 as a better
> starting point than the definition of SQL.

> However, if you want to propose and advocate an alternative to the
> relational model based upon some different logic, by all means do.

I will read RM/V2. I have the book, but not the time to read it yet. I have read RM/T and Codd's 1970 ACM paper. I understand your position "life is short" :-) I cannot propose an alternative to the relational model because "life is short" and maybe there isn't any alternative :-) It was just my feeling that binary is like machine code. I learned to trust some of my feelings :-)

> > I have not thought hard enough about it, but I suspect Codd had.

> However hard Codd thought about it, I suggest he did not think hard
> enough. Then again, perhaps he did and published his suggestions so
> someone else could overcome the difficulties he encountered.

Ok.

> >>>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.

>

> Enough for what? I do not know enough mathematics to prove Fermat's Last
> Theorem. I do know enough to compare proposed logical data models, to
> understand the predicate calculus and set theory upon which the RM is
> based, to effectively use Maxwell's and Shroedinger's equations etc.

Then you know more mathematics than me. :-)

> Although, I am sure if you search hard enough, you will find advocates
> of just about anything who do not understand what they advocate. In
> fact, I doubt one will have to search all that hard.

Yes. Myself. :-)

> >>>>>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.

> Pure mathematics is entirely experimental. I am less sure about applied
> mathematics.

That is a paradox :-) Received on Wed Apr 19 2006 - 08:38:20 CEST

Original text of this message