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 protected]> wrote: > On May 15, 2012, at 7:29 AM, Koen van der Drift <[email protected]> > 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 protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
