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 17:37:26 -0800
- Organization: Global Village Consulting, Inc.
Hi Steve,
Steve Sharman wrote:
2nd try at explaining, please ignore the first....!
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, a person can have only
one organisation
Many positions can be assigned to an organisation, a position can have
only one associated organisation
Happily this is not a problem.
As I understood it, this would mean:
person <-->> organisation
position <-->> organisation
with the associated foreign keys and relationships in place. For some
reason I didn't think that this was possible (or the right way to do
things) in EOF -
>
It is both possible and most definetley the right thing to do in EOF.
I thought there could only be a single to-one
relationship from a given entity. I don't know why I thought that....
something I've read and misunderstood probably.
If it is a valid join, it is a valid relationship. There are no
restrictions that I can think of. Modeling the exact same
relationship (same join, different name) would have potential to cause
problems.
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?
Now you know. Enjoy!
Chuck
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.