Re: Nested XML -> CoreData
Re: Nested XML -> CoreData
- Subject: Re: Nested XML -> CoreData
- From: Koen van der Drift <email@hidden>
- Date: Wed, 16 May 2012 12:34:42 -0400
Thanks for the feedback, very helpful. I will definitely swich to an
sqlstore, right now I am using xml for debugging purposes. I will also
create entities for each node.
- Koen.
On Tue, May 15, 2012 at 7:49 PM, Chris Hanson <email@hidden> wrote:
> 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