Re: CoreData Best Practices
Re: CoreData Best Practices
- Subject: Re: CoreData Best Practices
- From: John Timmer <email@hidden>
- Date: Fri, 29 Apr 2005 18:29:57 -0400
So, I only bring up the following because I'm interested in seeing the best
solution the list can come up with -
Two issues regarding your advice that are specific to bibliographic
information:
Most sources of author information (ie - PubMed) don't track individual
authors, so he'll essentially have no way of identifying when two authors
are identical. There will probably be an author for every instance of
authorship. He could match first, last and initials to save some space, but
it's not clear where the performance of the search vs. memory use of
separate instances falls, especially once the author list gets very large.
The second thing is that, although relating authors to the paper is easy,
retaining the order of the multiple authors for a publication is absolutely
essential. There has to be some way of reconstructing an ordered list out
of that relationship set.
I came up with:
Stick a unique ID in every author, and maintain an array of those which, as
you said, is suboptimal.
Stick an order key in every author, and use that to sort an array created
out of the set. This seems better, but commits you to having a unique
author instance for every place an author appears.
I have the nagging sense there must be something better, but I haven't come
up with it.
> To store the authors:
>
> Create an Author entity in your Core Data model and create a
> relationship between your existing entity and the Author entity.
> Create new Author entity instances, as needed, and relate them to
> your -- for lack of a better term -- Paper entity, as needed. If
> you are managing multiple Papers, it is likely that any one Author
> may be an author of multiple Papers and, therefore, you should use a
> fetch specification to grab an existing Author, if present, and
> relate that existing Author instead of creating duplicate Authors.
>
> With a reverse relationship from Author -> Paper, you could then ask
> an Author for all of its Papers. Core Data will take care of
> managing the inverse relationships automatically.
>
> To store the key/value pairs:
>
> Create a KeyValuePair entity that contains a 'key' attribute and a
> 'value' attribute. Then, create instances of those key/value pairs
> and relate them to your Paper entities, as necessary.
>
> Alternatively, you could store the values in a attribute marked as
> Binary, then use a derived attribute to archive/unarchive the
> dictionary/array into/out-of that attribute. This is suboptimal for
> a number of reasons and not really recommended, but can be useful in
> certain circumstances.
>
> ---
>
> In general, when creating the data model for your application,
> consider using managed objects for any place that you think you might
> need an NSArray or NSDictionary. An NSArray implies a
> relationship. NSDictionary implies an alternative form of data
> storage and is not hard to push into Core Data.
>
> b.bum
> _______________________________________________
> 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
_______________________________________________
This mind intentionally left blank
_______________________________________________
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