Re: Storing data and code in a Db with LISP-like interface

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 16 Apr 2006 18:58:11 GMT
Message-ID: <7tw0g.60938$VV4.1130211@ursa-nb00s0.nbnet.nb.ca>

JOG wrote:

> topmind wrote:
>

>>Nulls are a vendor-specific idea, not inherent to relational.

>
> While I agree with much of your post, nulls now appear to me to be
> essential to the relational model (whatever their rights and wrongs).
> If one fully normalizes a database then it is likely a join will
> require the use of null to pad the resulting virtual relation. Just
> because these relations are not persisted on disk, makes them no less
> 'relations' in the sense of Codd's algebra. As such i am currently
> struggling with how one can be against nulls (as per Date's perfectly
> justified view) but pro-RM from a completely theoretical standpoint.

With all due respect, is it possible you confound NULL with missing information?

Obviously, missing information is a difficult problem no matter what data model one uses. We currently have no theory regarding missing information which means we have no theory to overcome the practical problem in any data model.

In fact, missing information is rather anathema to science. Take interpolation for example: We either use sampling theory and error analysis to decide whether it is valid to interpolate, or we interpolate predictively as a method to falsify an hypothesis. Neither use accepts truly missing information as fact. Ditto for extrapolation.

In my opinion, Date and Darwen and others have demonstrated serious problems with NULL, 3-VL, 4-VL and "n-VL as n approaches infinity" even when applied consistently. The inconsistent mess of SQL just makes a bad situation worse.

Regardless whether one prefers NULL or systematized default values or no implicit 'support for missing information', which is what I prefer, one's choice will not really satisfy entirely.

I prefer 'no implicit support' in commercial systems on the Principle of Cautious Design. Give me adequate domain support (ie. type support) and I will model whatever is appropriate given the requirements. Accepting my choice, I must also accept that the modelling through the type system is work that must still get done when necessary.

I certainly commend Dr. Codd for attempting to tackle the problem, but I consider NULL the 'clay knapsack' of his work. Unlike the religious 'clay feet' from the Book of David, one can set NULL aside and the remainder of Codd's mathematics still stands on its own. Received on Sun Apr 16 2006 - 13:58:11 CDT