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: Andrew Farmer <email@hidden>
- Date: Sat, 31 Mar 2007 16:13:31 -0700
On 31 Mar 07, at 15:28, Guy Meyer wrote:
Consider a core data entity including a 128 bit attribute with few
possible values. Instead of including it in each managed object as
an attribute it can be set as a relationship pointing to a separate
entity which will store only a single copy of it.
When dealing with SQLite persistent store which of the above
options is more efficient as far as file size is considered ? a
relationship (i.e. pointer to another recored) or an attribute ?
What is equilibrium size ?
128 bits = 16 bytes = four ints. It'll probably be more efficient,
both in space and time, to store a separate copy in each object.
To say where equilibrium is, I'd have to know a few things:
- What file store type are you using? SQLite will have very different
characteristics than XML.
- How does that file store work? What's the overhead on each object
introduced by the file store and by the CoreData framework?
- Are indices involved?
This is probably the wrong way to go about handling the problem,
though. The more relevant question is, would it make sense (in the
database) to manage the underlying attribute separately from the
entries it applies to? If not, it probably shouldn't be in a separate
table.
_______________________________________________
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