CODEWITHSUNDEEP
iosentity-frameworkcore-datadatabase-designdata-modeling
Kris
Kris

Reputation: 155

Core Data multiple instances of same Entity - entities that share attributes

I am trying to wrap my head around how to have multiple instances of the same Core Data entity. It does not seem possible, so I must be approaching this wrong.

Basically, say I have a shopping cart that can be full of multiple balloons. But each balloon can have a different color. If I edit the template for the balloon, all the balloons will update to reflect the change. So say I change the template's name to 'bacon', all the balloon's names will change to 'bacon' as well.

How would I go about achieving this with Core Data?

EDIT

As requested I will try to clarify what I am trying to do.

Maybe this example will be more clear.

Say you are creating a model for exercises. So you have Ab Roller, Shoulder Press, etc.

In a workout, you may have multiple instances of each. So in one workout you will have, say

  1. Ab Roller
  2. Shoulder Press
  3. Ab Roller

And each instance of Ab Roller would have its own relationship to Sets which would be different for each of course.

Maybe not the best example but should give a clearer understanding of repeating instances.

I was thinking of having a template entity, and then an instance entity, and a relationship between them - when template entity name is updated, all instance entity's name update through KVO. Or I place all the shared attributes (i.e. name) in the relationship (so the instance entity's name attribute returns its template's name attribute) so that they reflect the changes to the template. What is the best way to go about it?

Upvotes: 1

Views: 1450

Answers (1)

Jo Douglass
Jo Douglass

Reputation: 2085

I'm going to answer this from a database design point of view, given the agreement in the comments that this is more a generic database design question. If that doesn't clear up all of your questions then hopefully someone who knows the ins and outs of Core Data can clear that side of things up for you.

You're looking at holding some configuration data for your system, and then also holding data for the various instances of entities which use that configuration data. The general pattern you've come up with of having a template entity (I've also seen this called a definition or configuration entity) and an instance entity is certainly one I've come across before, and I don't see a problem with that.

The rules of database normalization tell you to avoid data replication in your database. So if your template entity has a name field, and every single instance entity should have the same name, then you should just leave the name in the template entity and have a reference to that entity via a foreign key. Otherwise, when the name changes you'd have to update every single row in your instance table to match - and that's going to be an expensive operation. Or worse, it doesn't get updated and you end up with mismatched data in your system - this is known as an update anomaly.

So working on the idea of a shopping cart and stock for some sort of e-commerce solution (so like your first example), you might have a BasketItem entity, and an ItemTemplate entity:

ItemTemplate:  
* ItemTemplateId  
* Name  

BasketItem:  
* BasketItemId  
* ItemTemplateId  
* Color

Then your balloon template data and the data for your balloon instances would look like this in the database:

ItemTemplate: 

| ItemTemplateId | Name    |  
| 7              | Balloon |

BasketItem: 

| BasketItemId | ItemTemplateId | Color   |  
| 582          | 7              | Blue    |  
| 583          | 7              | Green   |

(This is obviously massively simplified, only looking at that one specific example and ignoring all of the mechanics of the basket and item, so don't take that as an actual design suggestion.)

Also, you might want to hold more configuration data, and this could drastically change the design: for instance, you might want to hold configuration data about the available colors for different products. The same concepts used above apply elsewhere - if you realise you're holding "Blue" over and over and realise you might in future want to change that to "Dark blue" because you now stock multiple shades of blue balloon, then it makes sense to have the color stored only once, and then have a foreign key pointed to wherever it is stored, so that you're not carrying out a massive update to your entire BasketItem table to update every instance of "Blue" to "Dark blue."

I would highly recommend doing some reading on database design and database normalization. It will help answer any questions you have along these lines. You might find that in some situations you need to break the rules of normalization - perhaps so that an ORM tool works elegantly, or for performance reasons - but it's far better to make those decisions in an informed manner, knowing what problems you might cause and taking further steps to prevent them from happening.

Upvotes: 1

Related Questions