• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Limiting number of assignments in a many-to-many relationship
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

References: 
 >Re: Limiting number of assignments in a many-to-many relationship (From: Denis Stanton <email@hidden>)
 >Re: Limiting number of assignments in a many-to-many relationship (From: Steve Sharman <email@hidden>)

  • Prev by Date: handles requests concurrently: problems
  • Next by Date: Re: handles requests concurrently: problems
  • Previous by thread: Re: Limiting number of assignments in a many-to-many relationship
  • Next by thread: Re: Limiting number of assignments in a many-to-many relationship
  • Index(es):
    • Date
    • Thread