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.
Now you're conflating other issues. This is why I recommend not
treating O/R systems as perfectly equivalent to databases. They're
not. On Snow Leopard & iPhone OS, you can make modest alterations to
the Core Data schema easily. Just keep a copy of the old model, and
pass the 2 keys to the options dictionary when you add the store to
the PSC to leverage light weight migration. Core Data will infer the
appropriate schema changes and adjust the schema in place (alter table
style).
<http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmLightweight.html#//apple_ref/doc/uid/TP40008426-SW1
>
If you do make some unusual and radical modifications (split tables
into multiple new tables, compose old tables into a single new table,
etc), you can use the full mapping model migration. While it won't
perform as well as light weight migration, at least you'll have tools
support in handling the schema migration.
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.
If this is important, than you can use multiple persistent stores.
I suspect Erik's point, though, is many apps don't have a significant
issue with a small amount of duplication in the individual documents.
Disk space is usually cheap. And being completely self contained has
its advantages (perhaps not relevant to you, but still existent).
"global" mutations is a double edged sword. What if your documents
are loaded in a newer version of the app, but have some implicit data
dependency on the older global data ? That can get messy.
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.
Then why not use Core Data for the database and for the entity
implement a simple NSObject subclass with a few instances
variables ... ?
Although, it seems a little silly to not use Core Data for the simple
part when you'll get persistence, change tracking and Cocoa Bindings
integration for free. Most people find NOT maintaining backward
compatible initWithCoder methods in perpetuity quite refreshing. I
know one developer seriously considering rewriting their iPhone app
for no other reason than to use Core Data's light weight migration and
never hand roll another database schema upgrade again.
Here's an excerpt from a post regarding when to use Core Data on the
iPhone:
"I suppose I could tell you how great an addition to Cocoa it is, or
how much TLC its performance tuning gets. But what I've seen our most
sophisticated clients decide is that it saves them from writing a lot
of code. The model code with Core Data is usually 50% to 70% smaller
as measured by lines of code. Why reinvent that ?
App developers don't get paid to write database code. Can you learn
SQL ? Sure. Do your customers care ? No.
App developers get paid for novel functionality that addresses a real
customer need with good UI.
- Ben
Here's a more traditional reply:
- Full KVC, KVO support out of box
- Relationship maintenance (inverses, delete propagation)
- Change tracking
- Sophisticated SQL compilation
- NSPredicate objects instead of SQL
- NSPredicate support for correlated subqueries, basic
functions, and other advanced SQL
- Proper Unicode, local aware searching, sorting, regex
- Complex queries just a simple setting on NSFetchRequest
- Futures (faulting)
- Lazy loading related objects
- copy-on-write data sharing
- partially materialized futures
- Merge policies
- built in version tracking & optimistic locking
- automatic multi-writer conflict resolution
- Performance Features
- lots
- 1/2 to 2/3 fewer lines of client app model code
- best memory scalability of any competing solution
- mature code base
- unit tested, qualified code base, millions of customers (every
Mac OS X deployment for years)
- expertise on performance, security, error handling
- Integration with Controller layer
- NSFetchedResultsController on iPhone OS
- Cocoa Bindings on Mac OS X
- Ease of use & tools support
- Model design tools
- File merge style diffing
- schema migration tools
- inferred, in place schema migration
- Interface Builder integration
- Instruments template & performance debugging"
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
