Re: foundations of relational theory?

From: Christopher Browne <cbbrowne_at_acm.org>
Date: 12 Oct 2003 04:39:05 GMT
Message-ID: <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>

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.

-- 
wm(X,Y):-write(X),write('_at_'),write(Y). wm('aa454','freenet.carleton.ca').
http://www3.sympatico.ca/cbbrowne/multiplexor.html
"``Normal'' people  don't like  things to be  powerful or  scalable or
reusable, just pretty." -- posterkid (posterkid_at_psnw.com)
Received on Sun Oct 12 2003 - 06:39:05 CEST

Original text of this message