Architectural question: one model, different properties

Hi everybody,

I'm currently trying to implement some kind of calendaring system which
manages a multitude of different kinds of events, and I am unsure about
how to represent them properly as models.

All these types of events have some common properties they share, like
a start date, an end date and an owner. However, they all also have one
or more properties distinct to them; for example employee vacations
might require a managers approval and therefor feature an 'is_approved'
flag, while bank holidays need to contain info about their recurrence
pattern, and so on.

What currently eludes me is how to deal with this in an elegant
fashion. While I could of course create either a single 'event' model
which contains the fields for all these types, or one model for each
event type, neither of those ways feel satisfactory and 'right'.

Maybe I just cannot see the forest for the trees, but how would you
deal with this? Would a base 'event' model with polymorphic
associations to specialized event type models be a good idea?

Thanks in advance for your thoughts,
Jan

Hi Jan,

It seems like any solution that requires you to add a new database
table whenever you want to add an event type is a bad idea.

To be honest, unless I had a million different types of event, I'd just
use a single model and set unused fields to null.

You're going to have to pay somewhere, either in maintaining multiple
database tables, coding some generic container
serialization/deserialization, or having a few null values. The last
seems cheapest to me.

Cheers,
Starr

That was exactly what I was looking for; so it's gonna be a single
table with STI.

Thanks a lot to you both!

Cheers,
Jan