ansaurus

Question

Core Data Model Design Question - Changing "Live" Objects also Changes Saved Objects

Answer 1

A:

I would go with your #3 as the clearest, most sensible option. It covers the intended usage of your (metaphorical) application well.

I ran into a similar situation a while back with an app that tracked tests administered to people; the tests contained multiple questions, and could be changed and re-administered on multiple dates. Having a test template, along with individual test objects, made the entire model much easier to deal with.

Tim 2010-03-29 19:46:12

Answer 2

+1 A:

I think you need to start over with your design.

(1) Why are using a PlayEntity as a template for the DownEntity? Entities are really (under the hood) classes so the class definition itself is the "template" for each instance.

(2) Managed Objects should represent data models of real objects or real information relationships. Therefore you need to think hard about what you the real objects or information you are trying to model. A good place to start is to ask yourself how this information would be recorded with pen and paper.

In your example, Plays and Downs model entirely different things.

A Down is an event ordered in time. There is only one particular Down in any particular game. This means every Down every played in every game in the history of football is utterly unique. A Down data model entity therefore would be primarily interested in modeling the Down's relation in time to other downs and the total game.

A Play by contrast is a spatial event. Plays are not unique and are often repeated within a game and from game to game. A Play entity should be concerned with the spatial relationships between players, the ball and the field.

You would end up with something like this:

DownEntity{
    game;
    half;
    quarter;
    turnover;
    gameClockTime;
    yardLine;
    penalties;
    play --(required,Cascade)->PlayEntity.down
    previousDown --(optional, nullify)-->Down.nextDown;
    nextDown --(optional, nullify)-->Down.previousDown
}


PlayEntity {
    playName;
    //whatever other detail you want to model
    down --(optional,nullify)-->>DownEnity.play;
}

Note that neither entity duplicates information held in the attributes of the other. Neither do they share inheritance because they don't model the same aspects of the game. The Down models a temporal sequence and the Play models a spatial one. It requires both of them to completely describe what happened upon each down.

You would build your database by first creating any standardized PlayEntities you wanted. If you had a novel play, you would create a new PlayEntity and populate it as needed. Every time you had a down you would create a DownEntity and create a relationship to an existing or newly created PlayEntity.

TechZen 2010-03-29 21:26:13

Perhaps my description of my current design is not detailed enough, and has lead to misunderstanding. What you are describing is all already in my design. Even the standardized "PlayEntities" that it starts out with. Your mock Down and Play entities look essentially like the ones I already have.

mwt 2010-03-29 21:50:16

The problem with the design you have here is the same as the one I have outlined above. If you change the details a PlayEntity, it changes the details of (the Play Entity) in all the saved Downs, thereby wrecking them as actual histories of what happened. I.e. the PlayEntity that it says was used is now actually slightly different than the one that was used.

mwt 2010-03-29 21:52:55

If each play can be different, then it would be best that the model reflect that by creating a different PlayEntity for each Down. There is no compelling reason to reuse PlayEntities unless they are in fact exactly duplicated within the limits of the model. You could have template data stored elsewhere to create Plays that are similar and/or ou could simply name plays that use the same basic form the same so you could do a search on all Downs whose play.name == "Right42. However, each actual instance of a PlayEntity would be unique even if its attributes are identical to another.

TechZen 2010-03-29 22:10:45

I believe something like this is what I'm suggesting in the #3 part of my question: having Play-Templates as well as Plays (or, as you would have it Play-TemplateEntities and PlayEntities). Play-Templates would be reusable, but Plays would be unique. I like your idea about the name search, as it helps to solve one of the downsides of the #3 solution (if Plays are unique, it makes it hard to fetch something like "all downs that use Play X").

mwt 2010-03-29 22:31:06

Yes, you should break up the entities to reflect different parts of the reality you are modeling. Since template plays and the actual play of each actual down are entirely separate real world objects (the first is in a book, the second happens on the field) they should each have a separate entity. One of the biggest mistakes people make when starting out in Core Data is trying to cram as much functionality into every entity as possible. Instead, you should do the opposite, breaking each part of the model up into smallest possible entities.

TechZen 2010-03-30 18:42:11

ansaurus

tags:

views:

answers:

Core Data Model Design Question - Changing "Live" Objects also Changes Saved Objects

related questions