Core Data model Design - Inverse relationship

Question

I have a fundamental design question in modelling the relationships between the entities for my application. Apple doc states Inverse relationships are very important to database integrity. I have three entities, Team, Player, Match with following relationships

Team <--->> Player
Player <--->> Team

The above relationship is straightforward, a Team can have many players, and a Player can belong to multiple teams.

Match:
homeTeam <---> Team
awayTeam <---> Team

In my Match entity, I have two properties homeTeam and awayTeam. Currently, their destination is set to Team with no Inverse relationship. Though application works I don't like the fact there is no inverse relationship to a match from a team. So, I am trying to figure what is the best way to setup inverse relationship for the Team entity. Also, I can't setup a one-to-one inverse relationship from team to match, since a team can play many matches. So, my initial thought is I can have a property matches in Team and make them the inverse relationship to a Match. Will this scenario work? or Do I need to create two inverse relationship properties like homeMatches, awayMatches in Team?

Thanks for any thoughts.

Javid

Answer 1

Do I need to create two inverse relationship properties like homeMatches, awayMatches in Team?

Yup. The inverse relationship needs to mirror the original relationship.

To understand why, consider what would happen if you had a matches relationship on Team which was set as the inverse of both homeTeam and awayTeam on Match: It looks okay for one direction of the relationship -- calling allStarGame.awayTeam = redTeam should add aMatch to redTeam's matches relationship. But what happens when you do it the other way around? That is, if you call [redTeam addMatchesObject:allStarGame], which of allStarGame's relationships gets used? It's undefined... that's why each relationship needs a distinct inverse.

Answer 2

I think your homeMatches, awayMatches idea should work well.

One other thing that jumped out at me is your relationship where a player belongs to more than one team. I assume that shouldn't be true for multiple teams at one time, which suggests that you might want some table in the middle (perhaps called RosterEntry) that would describe one player's time with one team. Team and Player would then be one-to-many with RosterEntry.