Re: Multiplicity, Change and MV

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 18 Apr 2006 13:45:57 GMT
Message-ID: <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.

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

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

>>>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. Received on Tue Apr 18 2006 - 15:45:57 CEST