Re: foundations of relational theory?

"Christopher Browne" <cbbrowne_at_acm.org> wrote in message news:bmctsd$le6if$2_at_ID-125932.news.uni-berlin.de...
> Oops! "Bob Badour" <bbadour_at_golden.net> was seen spray-painting on a wall:
> > "Christopher Browne" <cbbrowne_at_acm.org> wrote in message
> > news:bmalt8$k7ps6$2_at_ID-125932.news.uni-berlin.de...
> >> In the last exciting episode, dwolt_at_iserv.net (Dawn M. Wolthuis) wrote:
> >> > Apologies for the typo -- paragraph 2 should say "Is there some ...
> >> > that storing data that is NOT in first normal form is bad
.." --dawn
> >>
> >> It should be obvious on the face of it.
> >>
> >> If you have something that is being repeated an indefinite number of
> >> times, kludging it into fixed locations as in
> >> CHILD1, CHILD2, CHILD3
> >> is just _obviously_ horrible. The classic case would be the case of
> >> the employee with children:
> >>
> >> create table employee (
> >> id integer unique not null,
> >> name character varying,
> >> addressid integer,
> >> child1 character varying,
> >> child1birthdate date,
> >> child2 character varying,
> >> child2birthdate date,
> >> child3 character varying,
> >> child3birthdate date
> >> );
> >>
> >> That representation is just HORRIBLE. It leaves varying numbers of
> >> NULLs lying around for families with fewer children. It BREAKS if a
> >> family has a 4th child, as you either have to forbid that, or create
> >> some sort of "continuation" record.
> >>
> >> In XML, there's a "better way", as it is perfectly reasonable to open
> >> up a hierarchy thus:
> >>
> >> <children>
> >> <child><attributes/></child>
> >> <child><attributes/></child>
> >> <child><attributes/></child>
> >> <child><attributes/></child>
> >> </children>
> >
> > The latter is as horrible, if not more horrible, than the former. It
> > relies on relative position to identify items enormously increasing
> > complexity for no benefit whatsoever.

>

You do not understand what 1NF is. I suggest you go back to the books; choose good books.

> >> That's not terribly different from what Pick-like systems would do;
> >> they would happily stick the multiple children into the table with
> >> the parent, and have a treatment for having varying numbers of
> >> children.
> >
> > By pick-like, do you mean primitive file processors?
>
> No, by "Pick-like," I mean systems that allow having nested tables.

Pick has no tables let alone nested tables.

> I apparently don't have your need to insult people for finding Pick
> useful to their needs.

I insult people for vociferous ignorance. I have no problem with anyone finding Pick useful as a primitive file processor. Received on Mon Oct 13 2003 - 14:24:30 CEST