# Best practice - polymorphic or not

**URL:** <https://www.ruby-forum.com/t/best-practice-polymorphic-or-not/74074>\
**Category:** Rails\
**Created:** [October 29, 2006, 7:49pm UTC](https://www.ruby-forum.com/t/best-practice-polymorphic-or-not/74074 "2006-10-29T19:49:34Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![MartOn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/6a8cbe/32.png) [@MartOn](https://www.ruby-forum.com/u/MartOn)\
**Post date:** [October 29, 2006, 7:49pm UTC](https://www.ruby-forum.com/t/best-practice-polymorphic-or-not/74074/1 "2006-10-29T19:49:34Z")

</div>

Hello I have this scenario (hope it is understandable):

I have a model to support fact messages of different types. This is  
sport related and I have currently the following model design.

matchfacts (is the generic table connecting all matchfacts to for  
instance a match/game, match has\_many matchfacts).  
Some matchfact-data is generic, like the time of fact and therefore the  
data should be stored there.

Instead of making one table fits all, I want matchfacts to support  
certain predefined types.  
For instance: Goal, Substitution, Card and so on.  
What is best practice here? Use the polymorphic feature or create a  
model of each matchfact-type with a has\_one connection to matchfacts  
model?

The next problem is that each matchfact-type will probably also need  
either a enumeration or a matchfact-x-type model (where x is each  
matchfact-type (example of types can be: Red,Yellow card-types). This  
is to limit the different data beeing entered into model, but still  
make it dynamic and changeable by web-admin not database-admin.

/MartOn

---

<div class="post-metadata">

**Author:** ![MartOn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/6a8cbe/32.png) [@MartOn](https://www.ruby-forum.com/u/MartOn)\
**Post date:** [November 7, 2006, 10:52am UTC](https://www.ruby-forum.com/t/best-practice-polymorphic-or-not/74074/2 "2006-11-07T10:52:36Z")

</div>

I just want to clearify a little more why this is not solved with one  
table.

If we have a matchfact of type Goal. Goaltype must have one relation to  
player (the one who scored)  
If we have a matchfact of type Substitution, Substtype must have two  
relations to player (the one who got in and the one who got out).

Having one matchfacts table would give me a table with many columns and  
only some of them used at once.

/MartOn

---

<div class="post-metadata">

**Author:** ![MartOn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/6a8cbe/32.png) [@MartOn](https://www.ruby-forum.com/u/MartOn)\
**Post date:** [November 7, 2006, 10:52am UTC](https://www.ruby-forum.com/t/best-practice-polymorphic-or-not/74074/3 "2006-11-07T10:52:51Z")

</div>

MartOn wrote:

> /MartOn

You might want to consider using single table inheritance (STI) for  
this. A true polymorphic system might be overkill.

\_Kevin

---

<div class="post-metadata">

**Author:** ![MartOn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/6a8cbe/32.png) [@MartOn](https://www.ruby-forum.com/u/MartOn)\
**Post date:** [November 7, 2006, 10:52am UTC](https://www.ruby-forum.com/t/best-practice-polymorphic-or-not/74074/4 "2006-11-07T10:52:52Z")

</div>

Hi MartOn,

One rule of thumb I use is to decide if the application requirements  
for these items are more data-centric or behavioral in nature. If they  
are more data driven then I would tend to lump them in the same table  
but if behavioral then give them their own table. Having them in  
separate tables gives you way more flexibility and the opportunity to  
anchor them under a common superclass. This of course allows you to  
specify common behavior up in the superclass. Usually once you start  
down a certain path the best choice will make itself known.

Paul C.  
System Re-engineering, Inc.