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 22:04:40 +0300
On Apr 1, 2007, at 1:28 AM, 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 ?
On Apr 1, 2007, at 2:13 AM, Andrew Farmer wrote:
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.
On Apr 1, 2007, at 2:26 PM, Chris Hanson wrote:
Let your data model guide guide you, and normalize it as much as
possible at first. Since normalization is ultimately about
removing duplication of data, your intuition that you should use a
separate entity is correct.
You should avoid making these decisions purely on some technical
basis like "equilibrium size" if at all possible; even if it was
only 1 byte rather than 16, it might still make more sense in the
context of your data model -- that is, based on its meaning -- to
model it via a relationship.
-- Chris
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.
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