Re: Many to Many with a Twist

From: p.forestall <forestall_at_sprint.ca>
Date: 2000/07/25
Message-ID: <CLif5.351$fV5.10760_at_newscontent-01.sprint.ca>#1/1


... resending ...
"p.forestall" <forestall_at_sprint.ca> wrote in message news:...
> Van:
>
> I had this situation too. I think your current solution is the obvious
> relational one; it's the route I took. I had ten associative tables
 between
> a hierarchy of product entities and a cost type entity. The business rules
> required that many M:N relationships. I may get more soon! I tried several
> ways to get down to one associative entity but each solution essentially
> encoded relationships as attributes. The ERD looked neater but
 relationship
> rule maintenance was left entirely to code. That's not why I'm here.
>
> Your request made me wonder about my own definition of 'elegant'. One
> definition might be 'as simple as possible, but no simpler'. I think I
 heard
> that somewhere.
>
> Phil
> "Van Messner" <vmessnerNOvmSPAM_at_discovernet.com.invalid> wrote in message
> news:3cbf99c4.ca02cb89_at_usw-ex0106-046.remarq.com...
> > Thanks very much for the advice. I thought of subclassing, but
> > C, R and B are very different, and there are almost no common
> > columns. The superclass would be a completely artificial device.
> > Would a superclass then still be a "better" solution?
> >
> >
> > -----------------------------------------------------------
> >
> > Got questions? Get answers over the phone at Keen.com.
> > Up to 100 minutes free!
> > http://www.keen.com
> >
>
>
Received on Tue Jul 25 2000 - 00:00:00 CEST

Original text of this message