views:

39

answers:

1

I have two Core Data entities, say Account and House. Each account can have a list of houses and a house can only be in one account, so that's a regular one-to-many relationship with an inverse.

An account also has a "primary" property that indicates which of the many possible houses is primary or is nil if there are none. The identity of the primary property may change, and of course there may be many accounts, each with its own collection of houses.

Should I model this as a one-to-one relationship with an inverse? Without?

Or should I model it using an attribute, say that stores a unique piece of information about the house, such as a parcel number, and add that to the House entity?

What are the advantages and disadvantages to either method and is there another way I should be looking at?

+1  A: 

I would model it as a one-to-one relationship with an inverse. Although you could get away without the inverse.

It is recommended to always have an inverse (hence the Xcode compiler warning when there isn't an inverse in the data model). The only reason I can think of to not have an inverse is space. If you have a huge number of houses per account, it would save space in the database to have the relationship be one-way (from account to primary house only).

Your alternative of using an attribute in each entity would take up a similar amount of space in the database and be less useful. With the relationship you will have pointers between the managed object(s) rather than just a way to find them via an attribute.

gerry3
One advantage of the to-one relationship is that if I have a House I can find out if it is the primary by just looking in the inverse primary relationship.
Steve Weller