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