Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!elnk-pas-nf1!newsfeed.earthlink.net!pd7cy1no!pd7cy2no!shaw.ca!pd7urf3no.POSTED!53ab2750!not-for-mail X-Trace-PostClient-IP: 24.84.208.66 From: paul c User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 Newsgroups: comp.databases.theory Subject: Re: Proposal: 6NF References: <1159954091.119164.155490@m73g2000cwd.googlegroups.com> <%zOUg.8386$GR.2556@newssvr29.news.prodigy.net> <1159970386.339044.87090@i42g2000cwa.googlegroups.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 64 Message-ID: Date: Mon, 09 Oct 2006 23:50:02 GMT NNTP-Posting-Host: 64.59.144.75 X-Complaints-To: abuse@shaw.ca X-Trace: pd7urf3no 1160437802 64.59.144.75 (Mon, 09 Oct 2006 17:50:02 MDT) NNTP-Posting-Date: Mon, 09 Oct 2006 17:50:02 MDT Organization: Shaw Residential Internet Xref: dp-news.maxwell.syr.edu comp.databases.theory:45648 Hugo Kornelis wrote: > On Fri, 06 Oct 2006 23:29:29 GMT, paul c wrote: > >> Hugo Kornelis wrote: > (snip) >>> Because relational databases supporting NULL *define* it as a marker >>> denoting the absence of a value. Dawn actually makes a good point about >>> context: in C for instance, NULL has a completely different meaning. >>> ... >> Since it has a different meaning in C, there is no point bringing C into >> play here. > > Hi Paul, > > The point I was trying to make is that NULL has different meaning in > different context. Using C as example was a bad choice, since it > obfuscated what I was trying to convey, rather than clarifying it. > > The meaning of NULL in the context of SQL is also quite different from > the meaning of NULL in Pick (and possibly other MV databases). That's > what I wanted to write, and what I should have written in the first > place. Much of the discussion between Cimode and Dawn appears (as I read > it) to come from Cimode talking aboout SQL NULL and Dawn talking about > Pick NULL - but they both think that the other is discussing the same > NULL. > > This group is about databases in general, not just about relational > databases and definitely not only about SQL. The title of this thread > also doesn't limit discussion to SQL databases only. So it makes sense > to specify exactly what definition of NULL you're discussing - I think > that the Cimode-Dawn exchange would have been a lot shorter if everyone > had done that. > > Best, Hugo Hugo, that`s fair enough and sure, I don`t have any right to expect this to be a relational-only group, but I`m pretty sure when I see those two monikers that I know which one is in the RT camp. Just an aside, C being one of the two languages I`ve spent more than passing time with, I`ve always thought of it as a watered-down machine language. This is also its strength but I suspect its ubiquity causes some people to think it is an application programming language. It can be used for that, but usually that is an expensive choice except for specialty apps (as is C++ I might add). Ie., one usually uses C to program physical machines, not applications. There is a big difference. To me, it`s telling that some Pick afficionados might entertain a comparison with the NULL in a near-machine language like C. Whereas the null-less versions of the RM are not at all about physical machines. Pick very much came out of the era when all implementations were more concerned with the machine than with the application problem. I know, I was there! Vestiges of this mentality still exist, notably in the area of compilers and code generators where state-of-the-art still consists of programming the machine rather the application. Eg., the obvious target for compilation in the RM is as much relations-slash-tables as it is access statements or do-loops. When it comes to do-loops, my goodness, surely the cardinalities of tables would determine how many times the machine should iterate, not the programmer`s code. paul c.