Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
- Subject: Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
- From: "Melissa J. Turner" <email@hidden>
- Date: Tue, 28 Apr 2009 18:22:12 -0700
(apologies for the delay; I've been on vacation for the last few days
and just got back)
On Apr 28, 2009, at 14:32, Kyle Sluder wrote:
So step 1 is to stop clinging to normalization rules. (My database
professor would kill me for that sentence, but it's true.) There
really is no redundancy here, because the data stored on disk is never
really separated from the model objects which use that data. In an
n-tier app, you would be correct to avoid storing the derived
property.
Even in an n-tier application there are situations where it makes more
sense to denormalize data than cling to theoretical purity. Once
common case is to avoid joins, because they're *expensive*. Sometimes,
the dba level pain of maintaining duplicate/derived data is much less
than the user level pain of doing a join to display information in a
frequently accessed view. There's no general rule for when this
becomes true, because it's data set and use dependent, and it's not
something you should do casually or without understanding what you're
doing, why, and what tradeoffs are involved, but it is part of
building a schema that's does what you need it to do efficiently.
You can see an example of denormalized data in the Leopard version of
iCal. The badges on the corner of events in the varying day/week/month
views displays meta-information about the relationship that contains
the note/contact/etc data. Having the badge provides useful
information (there are other people invited, click here for meeting
material), but it's expensive to do the join just to decide whether or
not to display that badge for any given event, so iCal stores a
separate bit of information saying "this event has notes/contacts/
etc". According to pure relational design, this is a Very Bad Thing,
because it duplicates information that exists in the join tables and
introduces the possibility of error into the database. According to
real-world performance, not doing the join sped displaying those views
up by an order of magnitude (more in the case of large calendars).
Taking normalization to it's fullest extent, you end up with things
like databases where a Person is a set of joins to a Names table
(don't get me started on natural vs assigned integer keys ;-), but no
one outside academia does that because it's overkill and inefficient
for anything except theoretical work.
As for the logic required to maintain this relationship, that's why we
have KVC/KVO! Implement +keyPathsForValuesAffectingValueFor<Key>: as
appropriate. Implement your KVC setters/getters for the independent
attributes such that they invoke -setPrimitiveValue:forKey: for the
required dependent properties.
This is what I was getting at, yes. Create a separate modeled property
'letterGrade' and have the mutator for 'percentageGrade' automatically
update it whenever percentageGrade is changed. Add observers as
necessary.
+Melissa
_______________________________________________
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