• 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
Core Data: How best to create a data model for tracking changes to related objects?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Core Data: How best to create a data model for tracking changes to related objects?


  • Subject: Core Data: How best to create a data model for tracking changes to related objects?
  • From: Steve Weller <email@hidden>
  • Date: Sun, 11 Feb 2007 20:37:20 -0800


I have two entities, let's call them File and Folder and assume that all files belong to one folder and a folder can have any number of files (but not folders) in it. All files and folders have names and UUIDs so I can uniquely identify them.


I want a data model that tracks the creation and deletion of files and folders, so I create another entity call Transaction, the idea being that each transaction has a type (create or destroy) and a date that I populate as things happen. This will allow me to show a history of changes to a folder for instance.

I see two ways to implement this:

1. If File and Folder are different entities, then a Transaction has to have two separate relationships, one to Files and one to Folders, only one of which will be used. Also Files and Folders have very similar data (name and UUID) and that will require more code.

2. If I create an abstract entity called TrackedItem with a name and a UUID and make that the parent of Files and Folders then I can remove the name and UUID from them, and Transaction just has a to- many relationship with Tracked Item. This seems much simpler.

I thought that #2 was the way to go, but I saw this on Chris Hanson's blog:

"Another thing be careful of is entity inheritance. It's an implementation detail, but inheritance in Core Data is single-table. Thus if you have every entity in your application inheriting from one abstract entity, it'll all wind up in a single table, potentially increasing the amount of time fetches take etc. because they require scanning more data."

Since I want to be able to store a very large number of Files and Folders (and other things as well), this is not good. Which of 1 and 2 is best? And is there a third way?


-- Bagelturf Blog http://homepage.mac.com/bagelturf/



_______________________________________________

Cocoa-dev mailing list (email@hidden)

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: Core Data: How best to create a data model for tracking changes to related objects?
      • From: Scott Stevenson <email@hidden>
  • Prev by Date: [Moderator] List guidelines and related resources
  • Next by Date: Re: Customize NSAlert?
  • Previous by thread: [Moderator] List guidelines and related resources
  • Next by thread: Re: Core Data: How best to create a data model for tracking changes to related objects?
  • Index(es):
    • Date
    • Thread