Re: Proposal: 6NF

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:tFBVg.100563$1T2.19259_at_pd7urf2no...
> Hugo Kornelis wrote:
> > On Fri, 06 Oct 2006 08:32:36 GMT, Brian Selzer wrote:
> >
> >> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
> >> news:1159970386.339044.87090_at_i42g2000cwa.googlegroups.com...
> >>> Brian Selzer wrote:
> >>>> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
> >>>> news:1159954091.119164.155490_at_m73g2000cwd.googlegroups.com...
> >>>>> All of your points represent a wild goose chase in my eyes Brian. A
> >>>>> proposition with a NULL in it is no proposition at all. From a
logical
> >>>>> perspective, case closed. A relation tuple with a NULL in it is no
> >>>>> relation tuple at all. From a mathematical perspective, case closed.
> >>>>> Trying to invoke the 'kludge perspective' is hardly going to
convince a
> >>>>> theoretical newsgroup.
> >>>>>
> >>>> Is the empty set a value? Yes, it is. So why can't a null be?
> >>> Because an empty set is a value and a NULL is not.
> >>>
> >> Why not?
> >
> > Hi Brian,
> >
> > 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.
> > ...

>

Advancing the state of database theory involves (among many other things) looking at parts of existing theory (including the supposed theory behind existing implementations) and finding improvements.

The theorists in this newsgroup have demonstrated, repeatedly, that the problems that SQL NULL solves can be obviated by appropriate table decomposition. They have also demonstrated that fully normalized relvars do not need to support NULLS.
Even though I take issue with such theorists, the fact is that their answer *does* fall under the rule of "a systematic treatment of missing data". "Always obviate the need for nullable columns" *is* a systematic treatment of the problem.

My issue with that is not that it's a theoretically incorrect solution, but that it's often a lousy solution in practical terms. There are many in this news group who emphatically assert that, when theory and practice give divergent guidance concerning design, that practice must always yield to theory. That's the surest recipe for stagnation in the art of design.

I have very little use for such a stance. I have even less use for the opposing stance, namely that when theory and practice diverge, theory should always yield to practice.

So what does all this have to do with C? Well, it's possible that C has come up with a systematic way of dealing with missing data that is neither as unfortunate as SQL's way, nor as convoluted as the way of current relational theorists. And that's why it's possibly relevant to the discussion.

> p

>
> Received on Wed Oct 11 2006 - 03:09:24 CEST