dynamic naming for hierarchical problem

[gzeljko]

From: Alex Martelli <aleaxit at yahoo.com>
> "gzeljko" <gzeljko at sezampro.yu> wrote in message
> > TBL
> > ( PARENT, CHILD, CHILD_ATRIBUTE1,..,
> >  PRIMARY KEY (PARENT, CHILD))
> 
> 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.  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).
> 

Sory, it was just shorthand :)
Actualy, as I was using that, it was:

CREATE TABLE SOME_CATALOG (
  ID INTEGER, PARENT_ID INTEGER, NAME CHAR(20));

CREATE INDEX IX_SOME_CATALOG ON SOME_CATALOG (
  PARENT_ID, ID);   

CREATE GENERATOR GEN_SOME_CATALOG_ID; 

I was useing, before, this structure, with desktop databases also,
for outlook-looking aplications ( ID was, formaly, foreign key
in table with 'real data' )
I wasn't use constraints here, as computers was very slow 
and small :)

My point was that, for initial posters problem space, as I see it,
double-linked-list paradigm not needed (no need for 
child->parent link and solution can be feeted in single
dictionary (probably).

but-now-computers-are-fast-and-big-ly -y'rs,
gzeljko