Re: many junction tables

Oh, Ok. Now I understand. It seems that there is no solution
using SQL without using inheritance. I had some Ideas but postgres
has weird sematics (not conforming SQL99) using inheritance and so
it didn't work. But you should not - as you suggested - store the
tablenames in a "assocciation" table. That is no clean database design.
If I can get my ideas running, I'll post you.

Arne.

E Kolve wrote:
>
> The idea is this. Suppose I had say 40 or 50 tables like city or
> company (schools, purchases, etc) where I want to have a one to many
> relationship (One person can purchase many things, one person can attend
> many schools) I would have to create many junction tables
> (school_persons, purchase_persons, etc). What I am looking for is a
> solution to creating all these tables, if at all possible.
>
> --eric
>
> Arne Weiner wrote:
> >
> > I don't understand what exactly your problem is. What
> > what makes me unsure is: why do you want to store the
> > target table names in the association table?
> >
> > Eric Kolve wrote:
> > >
> > > I was wondering if anyone has a solution to the following problem. I
> > > have a few tables similar to the following.
> > >
> > > person_table
> > >
> > > city_table
> > >
> > > company_table
> > >
> > > If I want to associate a person with a one or more cities. I need to
> > > create a city_persons table that contains just the primary keys of both
> > > the city_table and person_table. If I want to associate a person to
> > > many companies, I have to do a similar thing. Now, if I wan to
> > > generalize these associaes I can create something like an associate
> > > table which will contain both id's plus two columns which indicate the
> > > source and target tables of the relaionship. Does anyone have
> > > suggestions along these lines on how to generalize such relationships?
> > >
> > > thanks,
> > >
> > > --eric
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 3: if posting/reading through Usenet, please send an appropriate
> > > subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> > > message can get through to the mailing list cleanly
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)