Re: Lots of Core Data Attributes
Re: Lots of Core Data Attributes
- Subject: Re: Lots of Core Data Attributes
- From: Jonathon Mah <email@hidden>
- Date: Fri, 1 Jul 2005 12:00:44 +0930
Hi Todd,
I'm working on a project that needs to store a lot of data about
individual people. Everything from names, titles and salutations
and multiple addresses to credit card information. My question is
this: Would I be better off making all of the fields as attributes,
or should I go with my current solution of using relationships for
the detailed fields (like addresses and credit cards) and only
using attributes for the more general info?
The advantage of splitting it up is that it will only be loaded into
memory when it's used. So if you have a lot of customers, only their
names will be loaded when you're displaying a list (say), and the
address will only get loaded into memory when you first display it.
(Until it's loaded, it's replaced with a dummy "fault" object.)
If you have multiple addresses, how would you do that without a
relationship?
I'm not entirely sure, but I think this faulting stuff only happens
when you use the SQLLite store.
Right now, it's set up to use attributes for the email addresses
and few other basic fields. Relationships are used for mailing and
shipping addresses, etc. The problem I'm having with this is that
creating objects manually is more work. Instead of just creating
one managed object, I have to create one for each relationship then
link them all together by hand. Am I going about this the wrong way?
I don't completely understand the question, but I think the only
extra work you should have to do is create an address object and
point the customer to it (maybe two lines). Are you implying there's
more work than that?
Jonathon Mah
email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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