re:[Core Data] Lightweight Objects
re:[Core Data] Lightweight Objects
- Subject: re:[Core Data] Lightweight Objects
- From: Ben Trumbull <email@hidden>
- Date: Sat, 10 Nov 2007 16:41:02 -0800
I have a core data application in mind, and I'm wondering what the
best way
to organise my model would be. The bit that has me concerned is that
I have
an entity (let's call it "aLog") that has associated with it an
ordered set
of 1 byte values that's variable in number. They are data samples
from an
device which captures data. There's no real limit on how many
samples might
exist in a log.
So, I could have:
aLog ----to many---> aSample
But that seems very wasteful, especially as the sample will probably
need an
Id number to keep sequence and possibly a reverse relation to say
which log
a sample belongs to. Multiply up by thousands of samples and that
seems
silly.
So I'm thinking it would be nice to store the samples in a property
of the
"aLog" entity. A String with no max length? A BLOB?
Given the limit is 16K, your first impression about just having a BLOB
that's an array of 1 byte values is probably best.
Informing that choice is a number of factors. Managed Objects are 48
bytes, with a 16 byte unique identifier. There is some caching, and
space needed for various features, and that roughly brings the
framework's per row overhead to 128 bytes.
Now, that's overhead for objects actively being used in memory.
Avoiding fetching data you don't need, and leaving that data
serialized on disk, is always preferable. This is basically analogous
to graphics rendering. You want to clip to the visible region. Why
draw stuff nobody can see ? Same thing for working with lots of
objects. Clip the working set. SQLite can, without any special
effort, handle millions of rows.
For especially fine grained objects, like your log data, it generally
doesn't make much sense to burn 128 bytes to hold a 1 byte value. You
might want to if it was really important to be able to search on each
individual element, possess inverse relationships, or independently
update each element (with conflict detection, undo, etc), or bind them
into the UI.
The key features the database offers to distinct elements are
searching and updates. If you don't need them, you can cluster things
together into coarser grained units.
So for your data, or similar data like large collections of vertices,
it's enough to update the whole array as one semantic value. You can
put them into a binary property, or use a transformable property on
Leopard.
If your log data could grow much larger, like megabytes, then you
might consider instead storing a URI to a file in the database, and
log directly into a file. The filesystem is very good with buffered
sequential operations. But at 16K that's not terribly interesting
(each file a minimum of 4K, with memory overhead to access running in
the 16K range)
- Ben
_______________________________________________
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