Re: Limiting number of assignments in a many-to-many relationship
Re: Limiting number of assignments in a many-to-many relationship
- Subject: Re: Limiting number of assignments in a many-to-many relationship
- From: Chuck Hill <email@hidden>
- Date: Mon, 12 Jan 2004 15:48:49 -0800
- Organization: Global Village Consulting, Inc.
I think you are stating the relations incorrectly, or at least
unclearly. "Many persons can be assigned to an organization." only
tell you about Organization, not about Person. Try focusing on the
singular of the object you are modeling.
Try this:
An Organization may have zero or more Persons assigned to it.
A Person may only be assigned to one Organization.
An Organization may have zero or more Positions in it.
A Position may exist in zero or more Organizations. (that one is a
little unclear to me. Is the 'Mail Room Clerk' position occupied
with two different people in two different organizations one position
or two? Is it a generic or a specific description? The answer to
this will dictate whether it is a one to many or many to many
relationship).
An Organization may have zero or more EmailAddresses assigned to it.
An EmailAddresses may only be assigned to one Organization.
This should help clearly define what is to one and what is to many.
Chuck
Steve Sharman wrote:
Denis (and all others who have thoughtfully replied),
Perhaps I should elaborate a bit more to try and explain my reasoning.
The reason that I've used many-to-many rather than a standard
one-to-many is that organisation (and person for that matter) will
participate in many other relationships, for example:
Many persons can be assigned to an organisation
Many positions can be assigned to an organisation
Many email addresses can be assigned to an organisation
As I understand it, that would mean that I would have one-to-many
relationships from person to organisation, from position to organisation
and from email address to organisation. I didn't think that this was
possible (or the right way to do things) in EOF. If I'm wrong, then
great - I've learned something tonight. If not, what would you say is
the best way to do what I need to do?
Best regards,
-- Steve
On 12 Jan 2004, at 21:16, Denis Stanton wrote:
Steve
This seems like a standard one-to-many relationship. Very easy. Why
are you thinking of implementing it as a many-to-many (much more
difficult) and then artificially restricting one of the "manies" to a
single item?
Surely you just need to add a foreign key to person, to point to
organisation, and then connect the two by dragging a link in EOM to
generate the "persons" relationship in organisation.
Denis
On Tuesday, January 13, 2004, at 09:49 AM, Steve Sharman wrote:
Happy New Year to all on the list.
I have a fairly simple question. In my application, I've implemented
a many to many relationship between two objects person and position -
with the obvious implication that each person may be assigned to one
or more position. I want to implement a similar relationship to
reflect the situation:
- There are many persons
- There are many organisations
- Many persons can be assigned to an organisation
- A person can be assigned to one and only one organisation
The way that I thought of approaching this was to implement a
many-to-many relationship in the usual way between person and
organisation, but implement a restriction at the Java level that
would ensure that a given person was assigned to only one
organisation at a time. Is this the best way to approach this
requirement, and does anyone have any pointers as to how it can be
most efficiently implemented?
Thanks in advance for your advice,
-- Steve
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
Denis Stanton
email@hidden
Home: +64 9 533 0391
mobile: +64 21 1433622
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.