views:

47

answers:

4

In Core Data, most of the time relationships are modeled bidirectional. But the docs say in another place:

It typically only makes sense to model a to-one relationship in one direction.

+1  A: 

The answer is determined by the referential integrity requirements you want to enforce. If updating or removing the object on either side affects the object on the other side of the relationship, you need two-way. However, if updating/removing the object on one side does not affect the object on the other, then a one way is a better model.

Take for example a parent-children model with a 0..n : 1 cardinality (I prefer the 1 : 0..n representation, but for the sake of argument let's reverse it). Adding a new child, updating an existing child or deleting a child has no effect on the parent object, so there's no need for the parent to know explicitly about all the children (except when it comes time to pay college tuition). However, removing the parent has an adverse effect on the children objects, as they need to be deleted or re-parented, otherwise are orphaned and in an invalid state. Thus, it's better to model it as a one-way relationship. Another example is inventory - parts catalog relationship, again with 0..n : 1 cardinality.

Franci Penov
If I use one-way relationships in core data, lets say from one to many others, and define a Cascade deletion rule, would this still have an effect? And how about Nullify deletion rule? Another: If SpecialAgent references ObservedPersion but ObservedPerson has no idea about SpecialAgent (no back-reference), and ObservedPerson gets deleted - in that case I would have to make sure manually that SpecialAgent doesn't link to that deleted ObservedPerson anymore, right?
dontWatchMyProfile
+1  A: 

It's a matter of ownership: usually it doesn't make sense to have a bidirectional relationship because an entity conceptually owns the other one.

Think about some examples. If you have a structure in which you have users and an user can have a simple bank account associated with him. If you make the relation bidirectional you mean that an user owns an account but also an account owns an user.

This will make sense because you don't want to delete an user whenever you delete his account. That's why usually you don't need to have it bidirectional: because it's an additional constraint that is not needed since most of the time you will have an entity that has the other but not vice-versa.

Jack
Ok, starts making sense. So the whole point of this sentence from Apple is, that *actually* bidirectional to-one relationships don't make sense, *but because of* automatic referencial integrity management this bidirectional relationship is needed. Is that correct?
dontWatchMyProfile
@dontWatchMyProfile -- Nailed it. If you don't use bidirectional relationships you have to manage the object graph manually. E.g A-->>B instead of A<-->>B, you would have periodically to do a fetch on all B and check if they were still valid. Sometimes, however, bidirectional just doesn't make any sense but you have to be careful with unidirectional graphs. They're not for novices.
TechZen
+1  A: 

I think you read the whole document about relations you referenced in your question.

The document also describes all disadvantages of using unidirectional relations, and that only under very rare circumstances it makes sense to create unidirectional relations.

As a general rule i would strongly recommend creating bidirectional relations, except you are knowing exactly why not to do so.

Martin Brugger
Yes, you're right. That's why I'm confused, because they write: "It typically only makes sense to model a to-one relationship in one direction.". So on the one side they say it's bad to not, but on the other side they say it makes no sense to do so. So what's the suggestion then? It's a bit paradox. I must admit my english suffers a little bit so this text sometimes appears pretty Old Age Chinese to me.
dontWatchMyProfile
+5  A: 

Within Core Data you should always use a bi-directional relationship unless you have an extreme edge case. If you use one directional relationships then you are going to incur performance penalties within core data itself as well as have issues with referential integrity.

Unless you know specifically why you need a uni-directional relationship then you should always do a bi-directional relationship; the rule is that simple.

While Franci's answer is interesting, I have to disagree with it. Even in the examples he provided you should have a bi-directional relationship. There are almost no situations where a uni-directional relationship is going to be a better fit.

Marcus S. Zarra
+1 Going to have to agree with this. Unidirectional relationships are seldom a good idea. Orphaned objects are a pain to manage.
TechZen
+1 Definitely, I really can't imagine dealing manually with reference integrity constraints.
unforgiven
Indeed, I tried hard to think of a good unidirectional relationship example. Wasn't able to find one that makes much sense. The drawback is just that it may look weird why DogFood has a relationship with a specific Dog, for example... ;)
dontWatchMyProfile