CODEWITHSUNDEEP
objective-ccore-data
jdog
jdog

Reputation: 10759

Model CoreData objects like SQL

Is it best practice to model CoreData objects exactly like your relational database? I know CoreData is NOT a relational db.

So would I have the following objects (I know I shouldn't have id fields in relationships):

Business 
Building (Business has many locations; relationship)
Location (building has a location relationship)
Coord (Locations has a lat/long coord)
Worker (work has relationship to business and to location)

Is this to much of a breakdown? Would it be better to just have a worker and that has a work address attribute and a business attribute? Should building just have address, city, state, zip fields rather than a relationship to location?

Upvotes: 0

Views: 61

Answers (1)

matt
matt

Reputation: 534893

One guiding principle here should be that faulting means no memory usage. This is usually very desirable (in fact, it's one of the main reasons you're using Core Data in the first place). A building with a location relationship means we don't have to load the location information just to load a building; instead, we fault, and fetch the location information only if it is actually needed.

But the opposite consideration also applies. You should resist the temptation to over-normalize your model. This is not a SQL database. A relationship means that we can't fetch the data without a separate loading stage. That takes overhead and time. So if you have single facts that you're going to want to access whenever you access an object, they should be in the object so that they are loaded with them.

In your case I'd say you're way overnormalized. Unless you are going to do something very interesting with coordinates, for example, I don't see why coordinates should not be part of a location. And unless you are going to do something locations as separate objects, I don't see why a building doesn't just have an address.

Upvotes: 1

Related Questions