Re: Core Data - SQLite persistent store file size optimization
Re: Core Data - SQLite persistent store file size optimization
- Subject: Re: Core Data - SQLite persistent store file size optimization
- From: Chris Hanson <email@hidden>
- Date: Sun, 1 Apr 2007 12:50:47 -0700
On Apr 1, 2007, at 12:04 PM, Guy Meyer wrote:
Thanks
As said I am referring to SQLite file format
It would make sense to manage the underlaying attribute separately.
The question is would it be efficient in case of ten thousands (or
even more) records. My intuition is that a relationship is much more
costly then the 128 bit attribute.
What leads you to believe that? I would strongly suggest not relying
on intuition when it comes to issues of optimization, but instead
relying on measurement.
If your application's performance isn't what you need it to be, and it
turns out that using a relationship for this is a bottleneck according
to measurement with Shark, then it may be worth de-normalizing your
data model to put this value in an attribute.
Otherwise, my intuition would lead me to the opposite conclusion; a
relationship is not necessarily more costly than an attribute. After
all, it's just a foreign key. And since you're talking about a one-to-
many relationship, you also won't wind up with multiple instances of
this object (the "one" side of the relationship) with the same value
in a particular managed object context.
Can you explain what it is you're trying to accomplish in terms of
your application's domain model, or in an analogous domain? That will
probably give us all a far better picture of whether this is really
something you need to worry about.
-- Chris
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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