Re: Core Data Fetch request very poor performance ??!
Re: Core Data Fetch request very poor performance ??!
- Subject: Re: Core Data Fetch request very poor performance ??!
- From: Chris Hanson <email@hidden>
- Date: Tue, 29 Nov 2005 12:26:33 -0800
On Nov 29, 2005, at 2:08 AM, Aurélien Hugelé wrote:
you are right on this point, but my application has a background,
and needs data migration from archive to sql database... i'm using
the good old "find and create" technique, so i load everything in
memory, find if it as already been stored in the database, and
create it if necessary...
I've of course read your several notes/messages/enhancements about
this technique (you proposed some nice ideas by the way in those
notes, thank you).
Ah, that makes sense. (And, thank you! I'm glad they were helpful.)
Yes, from a fresh point of view, i agree... but as i said, my
application is already written and working... i need to keep
compatibility with my older controller... i just modified some part
of my controllers to have wrapper over core data. That's why i have
very few relation ships : my Author object already exists (it is a
wrapper above AddressBook's ABPerson) and it is not easy to break
everything just for core data :P
Moreover, thanks to uniqueIds, i can resolve *at run time* the name
(and many other things) of the author (that can have been modified
by another application!). I do not store persons datas myself since
i'm based on AddressBook framework.
That also makes sense, though eventually you will probably want to
evolve your controllers to have a more "natural" fit for your Core
Data-based data model.
I would like opinions about entities properties and their design :
As i said above, Author and Recipients were, in my previous
version, NSMutableSet of uniqueIds (as NSString*) matching the
ABPerson uniqueIds in the addressbook, this allow the Person object
to be resolved at runtime with lastest informations from AddressBook.
I'm still a little confused about your data model. You've described
it as having Record and Email entities, are the above attributes of
these entities or are they entities themselves? From the above it
sounds like they're currently attributes, and that they're binary or
string attributes containing multiple values (which you may be
"breaking up" in -awakeFromFetch).
What I would do is, any time I have an attribute that is "plural,"
turn it into a to-many relationship to another entity.
Also, if you never create a Record that isn't an Email you may want
to combine the two. Sometimes it can be conceptually cleaner to use
inheritance even if you never use the base entities, other times it
may not be.
Now that i use core data, and can not rewrite everything from
scratch, how should i link persons to emails ? how can i use an
Author entity and Recipients entity to keep compatibility ? should
those entity only have one attribute which is "uniqueId",
containing the ABPerson uniqueId string ? is it better to archive/
dearchiving NSMutableSet of uniqueIds as an attribute of my Email
entity (like this i do not need to change anything in my older
controller)?
I just feel it poor to use to-many relations ships to entities that
just have one attribute...
It's perfectly fine to use to-many relationships to entities with a
small number of attributes, even just one. In fact, I would caution
people for conceptual reasons not to "overload" entities with lots
and lots of attributes -- give each entity only the attributes it
needs, and use relationships to represent the rest. This is similar
in concept to database normalization.
In the case you've described I would probably have lightweight Author
and Recipient entities with a "uniqueId" attribute as you say,
related to the Email entity. I would probably also have separate
Account, Mailbox, LinkedPerson and LinkedFile entities based on the
data model you've described.
-- Chris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden