views:

93

answers:

5

I want to make an Entity for Location with properties: latitude & longitude. Then, I want to set a relationship from User to Location, from Photo to Location, etc. Should I do it without creating an inverse relationship from Location to the others? Otherwise, how would I do it like that?

Thanks!

Matt

A: 

This is kind of a context-sensitive question, in that without the whole data model it may not be possible to come up with the best design.

But - latitude and longitude are modelled naturally as doubles. They should probably not be optional since an entity named "location" makes no sense without both. You should probably also model the circle of uncertainty in metres, you may not use it now but it could be very useful and it will cost you very little.

I do think you want to have an inverse relationship since it could be useful to start with location and find photographs taken within a certain distance of that location. I do not think you want to make photo and location a many:many relationship since saving data by attempting to reuse locations is false economy, it will make your code a lot more complex and save very few bytes. photo:location is more naturally 1:1 but you could benefit from adding a method like (NSArray*)locationsWithinMeters:(float)meters ofLocation:(Location*)thisLocation to return all locations "close enough" to some location - very good for finding all photos of some place.

Adam Eberbach
I disagree that you should not use an inverse to-many relationship between locations and photos. It has nothing to do with saving memory or storage. Models should reflect reality and relationships are themselves data. In this case, many photos may be taken in the same location and you might want to pick a location and find all photos taken there. The relationships in the model should reflect this real linkage as close as possible.
TechZen
It's a reasonable point of view but then how do you decide what locations are "the same"? Think about it with the aim of locating a landmark or recreating a photograph and you see that any rounding is best left to a configurable query. Better perhaps to keep Location as an exact 1:1 entity with Photo and add a Region entity with attribute span (diameter in meters) and centre, which can have many Locations.
Adam Eberbach
+1  A: 

In most cases, you want to create an inverse relationship.

Inverse relationships make maintaing graph integrity easier and, more importantly, inverse relationships reflect the real-world relationships between the objects, events or conditions that the model simulates. The point of an object graph isn't merely the dumb storage of bits of data but also the active modeling of the relationships between different parts of that data. In Core Data, relationships themselves are active data.

In the real-world, photos are taken in locations and inversely some locations have photos taken in them. An inverse relationship would model that reality and give you the option of searching for photos based on their locations.

TechZen
A: 

Apple made a CLLocation class. It's primarily designed for returning data from GPS, but it can be created independently. http://developer.apple.com/library/ios/#documentation/CoreLocation/Reference/CLLocation_Class/CLLocation/CLLocation.html

seano1
A: 

I think using core data to manage the photos and the lat and lon of where the photo was taken is just fine. But somehow using CD to manage the "location" is a bit strange. I think the reason you're struggling with this is because "location" doesn't really fit into this data model. As Adam suggest I would just sweep the photos and photos that are taken a within certain distance appart form a location. For instnace all photos within 1 Km of each other form a location. you'll probably have some overlap ...

you should check out the ADC sample code PhotoLocations

brown.2179
A: 

Okay, I know how to do this now. I can create an abstract NSManagedObject called LocatableObject. Then, I can make this the Parent of my other NSManagedObjects, like User and Photo. Then, I can make a relationship object on Location that points to LocatableObject and the inverse on LocatableObject would be location and would point to Location. Now, User and Photo will each have a location through LocatableObject. For now, though, I won't be storing the location of photos, so I'm just using Location and User has a location and Location has a user.

MattDiPasquale