Re: Storing data and code in a Db with LISP-like interface
Date: Sun, 16 Apr 2006 18:58:11 GMT
Message-ID: <7tw0g.60938$VV4.1130211_at_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.