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: Guy Meyer <email@hidden>
- Date: Sun, 1 Apr 2007 23:36:39 +0300
On Apr 1, 2007, at 10:50 PM, Chris Hanson wrote:
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.
Yes, actual test (which I tried to avoid) is better than intuition.
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.
The questions is what is the size of the said foreign key (core data
sqlite store relationship)
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.
I am sampling data at high rate, creating a plenty of objects. Some
of the information sampled may repeat itself with little variation.
Guy
_______________________________________________
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