Re: foundations of relational theory?
Date: 13 Oct 2003 01:07:26 GMT
Message-ID: <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.
No, the XML equivalent to a "not-even-1NF" representation of this would be
<employee>
<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" "_at_" "enworbbc")) http://www.ntlug.org/~cbbrowne/linuxdistributions.html Unix *is* user friendly. It's just selective about who its friends are...Received on Mon Oct 13 2003 - 03:07:26 CEST