Re: Nested XML -> CoreData
Re: Nested XML -> CoreData
- Subject: Re: Nested XML -> CoreData
- From: Chris Hanson <email@hidden>
- Date: Tue, 15 May 2012 16:49:08 -0700
On May 15, 2012, at 7:29 AM, Koen van der Drift <email@hidden> wrote:
> However, the data read with the parser needs to end up in my Core Data
> model. Obviously I already created a Person entity, but how do I add the
> phone numbers to it? Create a PhoneNumber entity with two attributes?
That would be a reasonable approach.
> Or
> stuff the PhoneNumbers array in an NSData object, and make that an
> attribute of the Person entity, and pull out the data when needed?
That would be working at cross-purposes to the framework.
> I see
> the advantage of the former, in case I want to find out which Persons share
> a PhoneNumber (or Address, Car, etc).
>
> I guess my question is, should I make my CoreData model as nested as my XML
> file is, with lots of small entities?
That’s definitely not unreasonable. You may not partition them exactly the same though. For example, your XML may have a unique label for each phone number. In your data model, however, you may have *three* entities instead of two:
Person
PhoneNumber
PhoneNumberLabel
And then you can have each PhoneNumber labeled “Home” in the XML may wind up pointing to the same PhoneNumberLabel instance, normalizing your data.
You might even use hierarchy in your model, if you have other things that are labeled.
For example:
Person
Address
PhoneNumber
Label
PhoneNumberLabel
AddressLabel
where:
entity Label {
string name;
};
entity PhoneNumberLabel : Label {
to-many relationship phoneNumbers
to entity PhoneNumber
with inverse phoneNumberLabel;
};
entity AddressLabel : Label {
to-many relationship addresses
to entity Address
with inverse label;
};
This way your concept of a “label” is used once per labeled entity. You will have duplication between the Home phone number label and the Home address label, though this (usually) isn’t something that’s an issue; you can address this too, if you want, via further normalization.
> Furthermore, converting an XML file into strings, arrays and dictionaries,
> and then converting it back to Entities which are stored in an XML
> structure in the store seems over complicated to me. Any thoughts on that?
Core Data provides management of object graphs over an abstraction of storage.
It’s up to the developer to choose the specific persistent store type that fits their application, though in most cases this will very likely be the SQLite persistent store type, not the XML persistent store type. That allows you to avoid bringing your entire object graph into memory at once; instead, only the parts of it that you’re accessing are read.
-- Chris
_______________________________________________
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