• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: IS-A relationships in core data
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IS-A relationships in core data


  • Subject: Re: IS-A relationships in core data
  • From: Daniel Child <email@hidden>
  • Date: Tue, 20 Nov 2007 12:50:30 -0500

So in the Core Data model, are they treated as two separate tables?

My SQL is rusty, but I believe you would be defining a field in each table linking the two. That was why I had the impulse to do this. The classic example from my DB book had:

CLIENT (clientID, name, amtDue)
PARTNERSHIP_CLIENT (clientID, taxID, managingPartnerName, etc...)
CORPORATE_CLIENT (clientID, contactPerson, phone, etc.)

The point is that you add the key of the supertype (clientID) into the subtype table, or vice versa.

The fact that Core Data does NOT do this makes it hard to know exactly how things are handled. Apparently, the relations are handled using surrogate keys (as stated in the response by Melissa Turner at Apple), but there is no option of whether or not to set them. It is not clear to me how to define my key fields. Supposing, for instance, I want two fields together to be the key field, is there any way to do that?

A related question is whether Core Data handles object-relational scenarios. The examples I've seen show you how to set basic attribute types (string, integer, etc.), and how to set 1-N or N-M relations. But what if you want one of those attributes to be an object of some kind. Do you choose NSData as the attribute type?

So one source of my confusion stems from the fact that Core Data can store data in SQLite format, but does not really work like SQL at all.

Another question is that, while Core Data can store data in XML format, can it really handle complex hierarchical structures like those in dictionaries, where there may be any number of parts of speech indicators, meanings, associated explanations or sample sentences, etc?

If Core Data can do this, then I should go beyond the initial tutorials and try to master it. If not, I should devote my time to something else that will. I would love to be able to use it, however, as doing things from scratch would be very tedious.

Thanks.

On Nov 16, 2007, at 2:29 PM, mmalc crawford wrote:


On Nov 16, 2007, at 11:06 AM, Daniel Child wrote:

When I name the two fields the same thing

Why are you doing this?
If OldEnglishWords inherits from Words, then it gets the keys from Words...

_______________________________________________

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


  • Follow-Ups:
    • Re: IS-A relationships in core data
      • From: mmalc crawford <email@hidden>
    • Re: IS-A relationships in core data
      • From: mmalc crawford <email@hidden>
    • Re: IS-A relationships in core data
      • From: mmalc crawford <email@hidden>
    • Re: IS-A relationships in core data
      • From: mmalc crawford <email@hidden>
References: 
 >IS-A relationships in core data (From: Daniel Child <email@hidden>)
 >Re: IS-A relationships in core data (From: mmalc crawford <email@hidden>)
 >Re: IS-A relationships in core data (From: Daniel Child <email@hidden>)
 >Re: IS-A relationships in core data (From: mmalc crawford <email@hidden>)

  • Prev by Date: Re: Horizontal-only scrolling
  • Next by Date: Re: IS-A relationships in core data
  • Previous by thread: Re: IS-A relationships in core data
  • Next by thread: Re: IS-A relationships in core data
  • Index(es):
    • Date
    • Thread