Re: foundations of relational theory?

From: Christopher Browne <cbbrowne_at_acm.org>
Date: 13 Oct 2003 01:07:26 GMT
Message-ID: <bmctsd$le6if$2@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.

No, the XML equivalent to a "not-even-1NF" representation of this would be

  <id>100</id>
  <name>Christopher Browne</name>
  <addressid>171</addressid>
  <child1>Billy</child1>
  <child1birth>2000-01-17</child1birth>
  <child2>Sally</child2>
  <child2birth>2000-02-22</child2birth>
  <child3>Jerry</child3>
  <child3birth>1997-11-07</child3birth>

</employee>

That involves something worse than "positional" indications of things.

It might make sense to enforce that the dates have to be in increasing order, and certainly that you wouldn't populate <child2> unless <child1> was populated. Expressing that in a DTD or XML schema would be pretty hideous, and unnecessary if a better representation was used.

The representation that I suggested earlier... <children>

  <child> attributes for child </child>
  <child> attributes for another child </child>
  <child> attributes for still another child </child>

</children>

Is certainly NOT horrible in the ways that the "worse-than-1nf" presentation with child1, child2, child3 is. It is NOT "positional;" it doesn't forcibly need to matter which child is in which position, in much the same manner that SQL result sets are not _necessarily_ returned in any order.

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

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

-- 
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/linuxdistributions.html
Unix *is*  user friendly.  It's  just selective about who  its friends
are...

Received on Sun Oct 12 2003 - 20:07:26 CDT