Re: Lots of Core Data Attributes
Re: Lots of Core Data Attributes
- Subject: Re: Lots of Core Data Attributes
- From: mmalcolm crawford <email@hidden>
- Date: Thu, 30 Jun 2005 20:27:45 -0700
On Jun 30, 2005, at 7:30 PM, Jonathon Mah wrote:
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. [...] I'm not entirely sure, but I think this faulting stuff
only happens when you use the SQLLite store.
Correct.
If you have multiple addresses, how would you do that without a
relationship?
You could add attributes for each different address...
homeAddressLine1, homeAddressLine2, homeAddressLine3, homeCity,
homeZip
billingAddressLine1, billingAddressLine2, billingAddressLine3,
billingCity, billingZip
This highlights the main disadvantage of using separate attributes as
opposed to a relationship!
You could instead define an Address entity and individual
relationships for each address:
homeAddress -> Address
billingAddress -> Address
which is rather less unwieldy. You could also instead define a
single to-many relationship:
addresses ->> Address
Then you can add an arbitrary number of addresses. Think of this a
little like multi-value lists in Address Book...
The main disadvantage of the relationships approach is that searching
is more complex. If you want to find all the people with an address
is in a given city, you must traverse a relationship. This isn't
difficult in and of itself: if you use individual relationships for
each address, you just create an appropriate predicate specifying a
key path instead of just a key. If you use the 'addresses' to-many
approach, however, it gets a little more complicated. If you want to
specify that the person's home address must be in a given city, you
have to add an additional constraint to the predicate (and by
implication a means of identifying what is a home address, what is a
billing address, and so on). Again, though, this isn't very hard.
More importantly, this additional complexity may have performance
implications. It's more expensive to do a join than it is just to
look up a value in a table. If you have to satisfy two constraints,
then that's further overhead. Unless your data set becomes very
large, though, this is unlikely to be an issue.
mmalc
_______________________________________________
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