dynamic naming for hierarchical problem

[Jeremy Jones]

Alex Martelli <aleaxit at yahoo.com> wrote in message
news:9l2uqm0eub at enews2.newsguy.com...
> "gzeljko" <gzeljko at sezampro.yu> wrote in message
> news:mailman.997499838.6140.python-list at python.org...
> > From: Jeremy and Debra Jones <dnjjones at yahoo.com>
> > >
> > > It seems like if you were to do it in a rdbms, you would need at least
> two
> > > tables:
>     ...
> > No, one table:
> > TBL
> > ( PARENT, CHILD, CHILD_ATRIBUTE1,..,
> >  PRIMARY KEY (PARENT, CHILD))

I really hadn't thought of it like that.  That would work...I learn
something new every day (especially in this news group :-)

> Something wrong with this constraint, since it implies a child may
> have multiple parents.  I think CHILD by itself needs to be the
> primary key.

That would work.

>Otherwise I agree -- no need to use multiple tables
> for a parent/child relationship.  Rather, since children appear to
> have varying attributes, you'll need to split THOSE off into a table
> of their own (with CHILD as a foreign key).

In the example that I was working on, the children (not of the same parent,
but in different tiers of the hierarchy) were of differing types and would
have different attributes and different quantities of attributes.  I don't
know if I spelled that out exactly like that initially, but immediately
under the root would be test sets.  The test sets right now don't have any
attributes of their own, but they do have children - tests.  The tests would
have an attribute of pass/fail and a reason why and commands as children.
The commands would have attributes of expected result, pass/fail, actual
result.  I suppose you could hack together a table that would accomodate all
of those different attributes and have CHILD as a foreign key, but it seems
it would be a pain to give it room to grow if I needed it to.  (I just KNOW
that I am setting myself up here for you guys to show me some dynamite way
to accomodate a dynamic set of varying numbers of attributes since it is
obvious that both of you have worked a lot more with databases than I have.
When you prove me wrong, I will gratefully accept the humiliation  :-)

I appreciate the posts.  They have definitely spurred me on to think
differently.  I am still inclined to think that the DOM/XML route will be a
more simple route for my specific problem.