How to store many item flags in core data

I am trying to do the following in my iPad app. I have a structure that allows people to create grouped lists which we call "Templates". So The top level CoreOffer(has Title) which can have many groups(has grouptitle/displayorder) which can have many items(has ItemTitle, DisplayOrder). As shown below. This works great, I can create Templates perfectly.

Image link http://img405.imageshack.us/img405/9145/screenshot20110610at132.png

开发者_JS百科

But once Templates are created people than can use them to map against the Template which I will call an Evaluation. A Template can be used many times. The Evaluation will contain a date(system generated) and which items from this particular Template have been selected.

Example below, people will be able to check particular rows in the screen below, this is then an Evaluation.

Image link http://img41.imageshack.us/img41/8049/screenshot20110610at133.png

I am struggling to figure out how to create and store this information in the core data model without duplicating the Template. (struggling coming from a SQL background!) In SQL this would involve something like an evaluation table recording each itemid and its selection status.

I expect its quite simple but I just cant get my head around it!

Thanks

---

The first thing you want to do is clean up the naming in your data model. Remember, you are dealing with unique objects here and not the names of tables, columns, rows, joins etc in SQL. So, you don't need to prefix everything with "Core" (unless you have multiple kinds of Offer, Group and Item entities.)

Names of entities start with uppercase letters, names of attributes and relationships with lower case. All entity names are singular because the modeling of the entity does not depend on how many instances of the entity there will be or what kind of relationships it will have. To-one relationship names should be singular and to-many plural. These conventions make the code easy to read and convey information about the data model without having to see the actual graphic.

So, we could clean up your existing model like:

Offer{
  id:string
  title:string
  groups<-->>Group.offer
}

Group{
  title:string
  displayOrder:number
  offer<<-->Offer.groups
  items<-->>Item.group
}

Item{
  title:string
  displayOrder:number
  isSelected:Bool
  group<<-->Group.items
}

Now if you read a keypath in code that goes AnOfferObj.groups.items you can instantly tell you are traversing two to-many relationships without knowing anything else about the data model.

I am unclear exactly what you want your "Evaluations" to "copy". You appear to either want them to "copy" the entire graph of any Offer or you want them "copy" a set of Item objects.

In either case, the solution is to create an Evaluation entity that can form a relationship with either Offer or Item.

In the first case it would look like:

Evaluation{
  title:string
  offer<<-->Offer.evaluations
}

Offer{
  id:string
  title:string
  groups<-->>Group.offer
  evaluations<-->>Evaluation.offer
}

... and in the second case:

Evaluation{
  title:string
  items<<-->>Item.evaluations
}

Item{
  title:string
  displayOrder:number
  isSelected:Bool
  group<<-->Group.items
  evaluations<<-->>Evaluation.items
}

Note that in neither case are you duplicating or copying anything. You are just creating a reference to an existing group of objects. In the first case, you would find all the related Item objects for a particular Evaluation object by walking a keypath of offer.groups.items. In the second case, you would walk just the keypath of the items relationship of the Evaluation object with items.

Note that how you ultimately display all this in the UI is independent of the data model. Once you have the objects in hand, you can sort or otherwise arrange them as you need to based on the needs of view currently in use.

Some parting advice: Core Data is not SQL. Entities are not tables. Objects are not rows. Attributes are not columns. Relationships are not joins. Core Data is an object graph management system that may or may not persist the object graph and may or may not use SQL far behind the scenes to do so. Trying to think of Core Data in SQL terms will cause you to completely misunderstand Core Data and result in much grief and wasted time.

Basically, forget everything you know about SQL. That knowledge won't help you understand Core Data and will actively impede your understanding of it.