Best practice - polymorphic or not

Rails
1

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

2

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

3

MartOn wrote:

/MartOn

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

_Kevin

4

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.