Re: Core Data performance advice... creating relationships.
Re: Core Data performance advice... creating relationships.
- Subject: Re: Core Data performance advice... creating relationships.
- From: Phil <email@hidden>
- Date: Tue, 15 Jan 2008 06:46:33 -0500
On Jan 15, 2008, at 4:37 AM, Martin Linklater wrote:
On Tuesday, January 15, 2008, at 09:15AM, "Phil" <email@hidden
> wrote:
Could you elaborate on why you changed your position? In reading
your
initial reply, I was inclined to agree that Core Data probably wasn't
the best solution in this instance (i.e. it's a decent-sized data set
and what was being described appeared to be a simple table join
scenario with no clear OO requirements.) What did you see in the
original post that caused you to believe that, in fact, this really
was a Core Data usage scenario? Understanding your thinking might
help people like myself who are still struggling with where to draw
the line on using Core Data vs. a relational approach.
I can't see why Core Data would not be applicable in this instance.
My code basically parses a load of SQL table create commands and
recreates the data within Core Data. Since Core Data supports an
SQLite backing store I don't see why data size of amount of
relational information would factor... My plan is also to leverage
Bindings and Core Data to simplify my UI code. Core Data's ability
to deal with complex fetch predicates is also a win for me since I
can let Core Data do a lot of the heavy lifting within my dataset.
You appear to be describing a traditional SQL database application
(your latest post with the schema seems to confirm it.) The first
half of what you wrote has me thinking 'probably not a great
application for Core Data.' The second half re: UI makes sense if you
understand the overhead you are going to incur and that the benefits
provided are worth it. Core Data is not just an OO wrapper to a
relational database. It uses SQLite as a persistent object store but
don't be fooled into thinking that this is the same thing. If your
application naturally translates to an OO environment (i.e. if you
were actually using an existing SQL database to persist objects which
in reality have some associated behavior), then by all means go for
it. If not, you may be disappointed (i.e. you think you're having
problems with a simple 2 table join now? Just wait until you start
trying to do multi-table joins with complex predicates) as you're
piling on considerable overhead for what may end up being a small
amount of benefit.
In fact the only downside I can see of using Core Data over a
'proper' relational database is that Core Data fetch requests return
the entire entity rather than specific entity attirbutes, but since
I'm only dealing with a single user application and relatively small
objects I can't see this minor performance problem being an issue at
all. Once my backing store is created I'm only really going to be
accessing it in a read-only manner. My plan is to store all
dynamically created user data in a separate object model, so as to
keep my data relationships as simple as possible.
There is much more to it than that as you are throwing a lot of work
'over the wall' to Core Data which has a non-trivial cost in terms of
performance and memory. If you are used to SQL with other relational
databases, you give up a whole lot of control and may find that you
need to alter your approach (i.e. it is not the spoon that bends, but
rather you) to certain problems because you can't necessarily tell
Core Data how to act on your requests or get it to see the most
optimal approach. So in the end you have to trust it and, like many
SQL engines from not too many years ago, it's not very bright. You
can use Core Data to provide much of the same functionality, but it
will not begin to approach the performance of a relational database
for traditional SQL workloads (even single-user with moderate sized
data sets) in my experience.
Core Data seems like the perfect fit for me. Plus it's a good
learning exercise 8).
Having said all this, if it's just something for your own use and you
also want to learn Core Data... that makes sense ;-)
I must add the caveat that I'm in no regard a 'Databse Programmer',
so my opinions may be pretty naive about this...
Similar caveat on my end: I have quite a bit of experience in the
relational database world but am still learning Core Data. (hence my
original question... so I'd appreciate enlightenment on where I'm off-
base in this reply.)
Thanks,
Phil
_______________________________________________
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