Re: I have read tons of theory...but still...one question

"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message news:ckumal$6op$1_at_news.netins.net...

No need to remind me about logic; I'm practically Vulcan that way.

> Nested lists (of one or more attributes) are
> ordered, but not keyed from the perspective of the toolset (that I work
> with) other than by the parent key and the position in the list.

Is the top-level table ("file"?) ordered?

This distinction doesn't sound too important to me; they use a nested list but one could imagine a nested relation just as well.

> However,
> the list can be searched using values of other attrbutes, so if there is
> another attributes that could be considered candidate keys, then a
> particular row could be accessed by knowing that value as well. In the case
> of the toolset I work with, the uniqueness of that value within the nested
> list would not be enforced by the database., but by the application
> (typically a wrapper servicing multiple applications).

Again, it is fairly easy to imagine a relational/unordered version of the same, with a key required and the nested relation unordered.

> > For example, let's say I have a relation of (l=letter, set-of-(i=int,
> s=string)).
> > l is the key of the outer table; i is the key of the inner table. (Or is
> it (l,i)?)
> >
> > Is this a legal table:
> > a,{(1,"hello")}
> > b,{(1, "world"),(2,"foo")}
> >
> > Two rows have a value 1 for some i.
>
> Yes, definitely!

Hmmm. I would think this is specific to the fact that you're used to nesting lists, and not relations. Lists would necessarily start the numbering over again, whereas a key might not.

> > It seems both right and wrong either way. This is pretty much my only
> > (current) point of confusion about RVAs.
>
> This is also the case with an RVA meeting SQL-99/SQL3 standards IIRC. For
> both the non-1NF (pre/"post"-relational) and the newer relational model,
> this permits you to retrieve child relations without an explicit join
> condition.

Wait! How does it permit that? I didn't follow.

> select * from table;
>
> above would yield a result set that includes 1 hello 1 world 1 foo
> as a single "row" of output.

Yoink! I didn't follow that.

> Think what it takes in SQL to get the
> following output from a typical structure
>
> Name .........E-mail addresses........Phone Type.....Phone Number
> John Doe jdoe_at_aol.com Home (123) 555-2783
> john_doe_at_msn.com Work (123) 555-1283
> Mobile
> (382) 555-2983
> Jane Ayee janeayee_at_a.net Mobile (732) 555-2182
>
> Notice how the multiple nested lists (multiple 1-M child tables) are
> handled. There is no assumption as there is witih SQL that a single row of
> output has data related to each other except through the parent.

I could imagine a relational, NFNF version of the above table. I assume that name:email is 1:m, and name:(phone type, phone number) is 1:m. Something like

{ Name:string, email:{string}, phone:{type:enum, number:string}}

Marshall Received on Mon Oct 18 2004 - 09:21:15 CEST