Re: foundations of relational theory?

"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.

> 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? Received on Sun Oct 12 2003 - 14:01:42 CEST