So I think, if I understand what Graham is suggesting, that in a relational DB design you would model this with three relations 1) Parent 2) children (which could be the same as parent) 3) active_children. If a child is active you insert it in the active_children set (relation is a particular kind of set). When no longer active, delete it. That could be modelled in CD, but Rick could decide if that actually solves his requirement. In CD, you'd still need the relationships and inverse relationships via the intermediate relation, so I'm not sure if this does solve his problem. But I think it shows that the relationships of ER can all be modelled using entities and the lack of clarity of "what's an entity and what's a relationship" disappears.
On 25 Jun 2013, at 11:01, Graham Cox <graham....@bigpond.com> wrote: > > On 25/06/2013, at 12:49 AM, Flavio Donadio <fla...@donadio.com.br> wrote: > >> Rick Mann, I don't understand why you need a separate relationship to >> retrieve the active Child objects. Please, consider doing this: >> >> Parent >> children to-many to Child >> >> Child >> parent to-one to Parent >> active (boolean) >> >> And then create an activeChildren: method in Parent with returns only the >> active children. >> >> Sorry if this is not acceptable. I am just trying to help. > > > In my experience, this is not a good design pattern. > > It's common to want to maintain a subset of some collection (and it may be > that the subset can have at most a single member, as in Rick's case). Using a > boolean as a state variable in the objects to indicate membership of this set > is poor design because it a) requires a lot of management to turn off those > that become deselected, and b) requires much more time to iterate over the > collection to find the subset when needed, c) requires additional work if > there can be multiple, orthogonal sets of this nature. > > Using the language of sets it becomes clear how to do this much more > efficiently: use a set! The NSSet class, and its cousin NSIndexSet, are ideal > for this purpose. If it's in the set it's a member, otherwise not. It's fast > and efficient, simple to extend without the member objects ever having to > care about it. Sometimes the member object will want to ask "am I a member of > such-and-such a set?", and this is where the child->parent relationship can > be used. > > This is independent of Core Data, I'm not sure what features it has to > support this concept - maybe none, as typically this sort of subset > (selection) management is handled at the controller level. > > I commend it to the house. > > --Graham > > > > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/ianjoyner%40me.com > > This email sent to ianjoy...@me.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
