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
Yes IMO thats good, factor out binary data. It actually ends up being
faster in the long run. Thats assuming that those 1byte values are
going to be longer than just.... one byte. Right?
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.
Have you seen the benchmarks on CoreData on Leopard? They are wicked
fast.
I wouldn't be worried.
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?
Arrays of bytes, should be BLOBs no?
Any suggestions?
Your original idea, I think is better.
Lets say, for some analysis you want to do later, you want to grab all
samples, but you don't need the log information... well, how do you do
that efficiently if they are the same entity? (This is assuming the
aLog entity ends up having lots of fields populating it)
Having an inverse relation lets you get that info, only when you need
it, like say there was an anomaly in the sample... its best to factor
out A) data that will be accessed very very often, and B) BLOBs.
Thats just my opinion though!
Andre
Paul
_______________________________________________
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
