> Your example however has an interesting problem. What if a
> customer has 2 relationships with Address: visitor and
> billing address?
In that case, we specify which attribute in the Customer object is the
"graft point". Ala: customerQuery.AddJoin(Customers.Attributes.ShipAddress,
Address);
We
> > data isn't read into the objects out of nothing when you want it,
you
> > have to order some code to get it
>
> In our persistent framework, merely copying a object's
> properties doesn't cause objects to load, once on those
> properties is "dotted", that causes the object to be
> transpar
> Now, the manager thinks he needs to know when
> each employee
> started at which department. To model this correctly, you
> have to objectify the department-employee relationship into a
> relation, and add a non-pk, mandatory attribute 'StartDate'.
>
> Now, go back to the code
> > [...] After all, the m:n link table IS an entity, by definition of
the
> > relational model. [...]
>
> Not just an entity, however. ER modelling would recognize it
> as a *weak* entity.
True, however it's not ignored. It's a little nittpicking, but I
wanted to illustrate the genera
Now, the manager thinks he needs to know when each employee
started at which department. To model this correctly, you have to
objectify the department-employee relationship into a relation, and add
a non-pk, mandatory attribute 'StartDate'.
Now, go back to the codesnippet I just po
> data isn't read into the objects out of nothing when
> you want it, you have to order some code to get it
In our persistent framework, merely copying a object's properties doesn't
cause objects to load, once on those properties is "dotted", that causes the
object to be transparently loaded. It'
James,
> I would like to hear what you consider a 'GOOD Design!'
> approach for many to many relationships and Application code.
My point was that I've seen implementation in which linking tables were
directly translated to entity classes. That was wat I considered 'bad'.
Consider f.i. a relatio
Frans,
> [...] After all, the m:n link table IS an entity,
> by definition of the relational model. [...]
Not just an entity, however. ER modelling would recognize it as a *weak*
entity. The linking table in the relational database typically will not be
biased towards either of the two linked tab
