I have a entity called Item, and every item can have two or three bonuses...

What would be a good model design in this situation. I can think of something like:

To have many optional attributes inside Item entity i.e.


  • fire_rate_bonus

  • energy_bonus

  • damage_bonus

  • health_bonus

  • some_other_bonus

And then when creating an item, I would set the values for appropriate bonuses and rest of attributes will be set to null.

I find that this approach solving my problem, but is there some other/better/efficient way? If you need more info about this, I will update my question. Thanks in advance...


Doing like above in my case will do the job, because I don't have much possible bonuses. But let's say there is a lot of possible bonuses, and an item can have only few bonuses. Then I think this method could be overkill because:

Item entity will have too much unused attributes.

What I can think of (I know that Core Data is not relational database system, but I like to think in relational way) is to make new entity called Bonus with relationship between Item entity (one Item can have many bonuses) with attributes :

bonus_name, bonus_modifier or something like that.

And then when creating an Item just assign appropriate bonuses to it. I hope this make some sense.


2 Answers 2


I can see you going about this two ways without changing too much of your core data model.

Kind of a lazy way to do it if you know that there will be no more than 3 bonuses per item.

  • bonus_1_type (NSInteger)
  • bonus_1_amount (float)

  • bonus_2_type

  • bonus_2_amount

  • bonus_3_type

  • bonus_3_amount

This would give you the flexibility to use an Enum for type and float for amount.

The other way is to create a BonusEntity as you were talking about in your edit with a one to many relationship.


  • bonuses one to many BonusEntity


  • bonus_type (NSInteger)

  • bonus_amount (float)


Some additional thoughts. Keep in mind I am making some assumptions as to what a bonus actually is.

Lets say you have bonus types of FIRE_RATE, ENERGY, DAMAGE, HEALTH.

So adding a bonus would be.

bonus_type FIRE_RATE bonus_amount .25 (this would be an increase rate of .25)

bonus_type HEALTH bonus_amount 50 (this would give you 50 extra health)

Now keep in mind this is best if you are going to subtract from these values. Take HEALTH for example. You get hit and that item now only has a bonus of 25 left.

Now if these are more or less static you can do something like this.


Knowing that HEALTH_LEVEL_ONE will always give you 25 extra, HEALTH_LEVEL_TWO will give you 50 extra etc. Now you only need to manage bonus_type in core data and code will determine the amount.

Hopefully that helps.

  • \$\begingroup\$ Thanks Skyler, I will try both ways. Is there any reason not to use just one attribute for each bonus, with type of float, instead of two attributes like in your example (bonus_type,bonus_amount) for a single bonus? Type of bonus will be determined with an attribute name in code later. Am I missing something here ? \$\endgroup\$
    – Whirlwind
    Commented Mar 12, 2015 at 12:40
  • \$\begingroup\$ I added to my answer to hopefully better explain what I am thinking =) \$\endgroup\$ Commented Mar 12, 2015 at 13:21

That is a fine way to do it. Alternatives would be

  • A field on the item specifying which attribute the bonus applies to, with a modifier ie

    [{"fire_rate", 5}, {"health", 10}]

  • Each item could have a pair of delegates so you can make changes programatically. One applies the item's attributes, and optionally, the other removes them (like for equipment)

However, these two options are probably overkill for what you're going. Keeping with the YAGNI principle I strongly suggest sticking with specific modifiers like you've stated.

  • \$\begingroup\$ thanks for your reply, I just checked the link you gave me, and that's exactly what I was worried about. To do things in most simplest and if possible most performant way. Can you please check my edit. \$\endgroup\$
    – Whirlwind
    Commented Mar 12, 2015 at 11:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .