Re: Is Core Data appropriate to my task?
Re: Is Core Data appropriate to my task?
- Subject: Re: Is Core Data appropriate to my task?
- From: Gwynne Raskind <email@hidden>
- Date: Thu, 10 Sep 2009 15:51:57 -0400
On Sep 10, 2009, at 3:21 PM, Erik Buck wrote:
Yes. Use Core Data. Your application is exactly what Core data is
intended to support.
Create a planet entity.
Create a one to many relationship so that each employee has one
planet, but each planet has an unlimited number of employees.
This is exactly what "lookup tables" in sql produce. There is no
need for fancy fetched properties. There is no problem with having
planet entity instances in the same store with employee entity
instances. It is a good design that makes your data stores self
sufficient. There will only be one instance of the planet entity
for each planet that you define. Right now, you would never have
more than 8 or 9 planet entity instances no matter how many employee
instances you have.
You could also just have a "planet of origin" string property in
each Employee entity. The property could default to "Earth". There
is no need for a custom "Enum" type when strings work perfectly
well. You can even validate the strings whenever they change to
restrict the set of valid strings. Constant strings will tend to
have the same pointer, so you won't even have the cost of separate
string copies for each Employee instance.
I don't see this as being equivelant at all.
Extending the example, let's say the company with these Employees has
as its directors several discriminating unfair people, and thus an
Employee from any given Planet gets a salary adjustment based on that
Planet. The obvious place for this data is the Planets "table", or in
Core Data's case, the Planet entity. A "salaryAdj" column (attribute)
is added to the Planets table (Planet entity) and filled in with the
(in)appropriate numbers.
Now suddenly the company is taken over by far more benevolent and
considerate people, whose only flaw is that they don't want to break a
system that works by removing an entire column from a database table
(a schema change is much more difficult than a data update, after
all), so they just UPDATE Planets SET salaryAdj=0.
So someone loads up an Employee whose Planet instances are in the same
store with that Employee, and the old salary adjustment is still
sitting there in the saved data. I sense unhappy Employees in this
company's future. If only the coder who wrote the payroll system had
put the Planet data in some global store where changes to it would
propogate correctly to all Employees.
Does Core Data still solve the problem? Is there some reason that
using Core Data for everything would be better than storing the global
rarely-updated data in a "real" database and using Core Data only for
the Employee entity, which is the only part which really talks to the
UI anyway? (Something tells me the key point is right there...) For
that matter, if Core Data is only managing one entity, what's the use
of Core Data at all? With all the data being referential between the
database and the entity, just define a simple NSObject subclass which
contains a few instance variables and implements NSCoding.
-- Gwynne
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden