4

I'm struggling with a database architecture decision for a Rails app.

We have lots of different organizations and each organization has marketing assets they can sell. Examples of these marketing assets include:

  • Banners
  • Jerseys
  • Web banners
  • Email blasts

Each of theses assets have different properties. A banner has height, width, placement location attributes. A jersey has logo type, placement location, and logo type attributes.

What would be the best way to implement this? I've considered:

  • Attributes on the organization model - This is messy, hard to maintain and seems to violate the single responsibility principle
  • Polymorphic association - The specifics of each asset make me think that this isn't the right implementation either
  • Single Table Inheritance - I'm leaning towards this. I'd implement a base class called assets that has common asset attributes and tables like "Banners" that inherit from the base class. However, seems really hard to maintain and messy.

Anyone have thoughts here? I'm looking for something that is easily maintainable, scalable, and adheres to standard architecture practices.

Eric Stein
  • 13,209
  • 3
  • 37
  • 52
Zubin
  • 393
  • 1
  • 3
  • 7
  • STI is more well-suited to classes that share a lot of fields and functionality. It seems to me that these marketing assets vary pretty significantly. I think that makes a good case for a polymorphic association. If you choose STI, as the different marketing assets grow to require more fields, you end up with a lot of unused columns for each type. It clutters the table quite a bit – Brennan May 01 '17 at 20:54
  • Thanks for your insight @Brennan ! Each asset has two shared characteristics (currently_offer and willing_to_offer). Does that justify STI, should have separate models, or use a polymorphic association? – Zubin May 01 '17 at 21:18
  • 2
    There are going to be more fields *not* shared than shared, and I think that should disqualify STI in this case. By using polymorphic associations, your individual tables stay clean, you get the shared functionality, and still have flexibility to handle the subclasses as you wish. Since the individual assets form an `is-a` relationship with the parent `MarketableAsset` but have significantly different fields, I think polymorphic makes the most sense here – Brennan May 01 '17 at 21:22
  • 1
    What drives my decisions between STI and polymorphic associations are simply how much the related models share. If the fields are going to be pretty much the same for all child models, I choose STI. If those fields vary quite a bit, I choose polymorphism. – Brennan May 01 '17 at 21:25
  • @Brennan Super helpful in thinking through this and future problems. Thanks!! – Zubin May 01 '17 at 21:43
  • @Brennan in looking over this and reconsidering, how would you use a polymorphic association in this scenario? Instead, I would think that each organization would have_one :banner and have_one :jersey and we would create separate models for each. – Zubin May 01 '17 at 22:02

0 Answers0