On Aug 5, 2008, at 4:08 PM, Jacques Le Roux wrote:
From: "David E Jones" <[EMAIL PROTECTED]>
On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote:
From: "David E Jones" <[EMAIL PROTECTED]>
It might be better to have an independent ID for the
TerrestrialPosition (like terrestrialPositionId) and have things
point
to it rather than having it point to other things. In other
words we would add a terrestrialPositionId to the ContactMech
instead of putting a contactMechId on TerrestrialPosition. In
that way anything could point to it.
Yes and this is even simpler. I followed the PartyContactMech
pattern because I thought it was a best practise. But obviously
like that the scope will be wider.
This is something we should maybe discuss more, ie whether the
TerrestrialPosition should be a type of ContactMech or it's own
independent thing. I was thinking the independence might be
better, and we would have more control over what it is attached to.
In other words, the use patterns and relationships to other
entities are a little different than what is done with ContactMechs.
Still, if anyone thinks otherwise... please share.
Actually what I said above is not true. The scope will not be wider.
You can get the same using the ContactMech pattern. It's only a bit
harder since you have to create a specific entity (like
FacilityLocationContactMech) and make the association between the 2
other entities each time you want to relate a new entity (like say
FacilityLocation). In the second case only one association to
TerrestrialPosition would be needed. So it's up to you guys,
sometimes breaking the rules is good, sometimes it's not, we have to
really think about it ... before...
What do you mean by "break the rules"? I don't see any rules being
broken here...
As with anything you design to requirements, and try to make things
flexible but many-to-many relationships are not inherently better in
any way than many-to-one relationships, they are just different and
better for use in different situations.
-David
