Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnews.google.com!j33g2000cwa.googlegroups.com!not-for-mail From: "JOG" Newsgroups: comp.databases.theory,comp.databases.object,comp.object,comp.lang.lisp Subject: Re: Storing data and code in a Db with LISP-like interface Date: 16 Apr 2006 18:49:47 -0700 Organization: http://groups.google.com Lines: 88 Message-ID: <1145238586.997973.237640@j33g2000cwa.googlegroups.com> References: <1143603638.582373.250560@i40g2000cwc.googlegroups.com> <1144029234.495256.11540@u72g2000cwu.googlegroups.com> <1faYf.1074$jf7.210@trndny08> <1144111042.600878.64360@i39g2000cwa.googlegroups.com> <1144875417.086085.233560@u72g2000cwu.googlegroups.com> <1144970480.735546.107610@i39g2000cwa.googlegroups.com> <1145082222.873845.78540@v46g2000cwv.googlegroups.com> <1145135713.211047.70880@e56g2000cwe.googlegroups.com> <1145168430.751903.230360@e56g2000cwe.googlegroups.com> <1145189304.593238.68080@g10g2000cwb.googlegroups.com> <7tw0g.60938$VV4.1130211@ursa-nb00s0.nbnet.nb.ca> NNTP-Posting-Host: 62.254.0.48 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1145238592 12019 127.0.0.1 (17 Apr 2006 01:49:52 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 17 Apr 2006 01:49:52 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: j33g2000cwa.googlegroups.com; posting-host=62.254.0.48; posting-account=WQE_Eg0AAACz0MT8Z7vkSN2k8y0AQ1oA Xref: dp-news.maxwell.syr.edu comp.databases.theory:38119 comp.databases.object:13474 comp.object:138307 comp.lang.lisp:166362 Bob Badour wrote: > 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? Quite possibly Bob, and if so I stand corrected. I was referring to fill values generated via outer joins, which are of course not synonomous with the black holes that are SQL NULLS. I presonally avoid external joins as much as possible, but they seem prevalent enough that (if I recall correctly) they figure in Date and Darwen's D. > > 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. > Tell me about it. I'm of the view that if my data is missing and I can't satisfy the required predicate, I shouldn't be entering it into the damn extension at all. What can you do - I shut my eyes and type it in. I'm not convinced its an intractable issue yet, but I certainly have no solution. Inapplicable attributes I draw the line at - but you wouldn't believe the general state of data management in scientific fields that your forced to work with (in the name of diplomacy). Finances are prioritized for new hardware rather than corresponding informatics development that could double productivity. There was a recent editorial in Nature about this very bottleneck, but to be honest, I doubt much will change any time soon. > 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. Yes, Date and Darwens arguments are incontrovertible as far as I'm concerned. I spoke at a degree-level database class recently and was pleasantly suprised that they were actually marked down if columns were not specifed NOT NULL, and encouraged to decompose if missing values for an attribute was a likelihood. > > 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. This area always reminds me of Rumsfeld's quote on intelligence in the middle east: "Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know." He should have cited Date.