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
–
Check out my blog for startups and upstarts: www.thebootstrapnation.com
Elektroholunder wrote:
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.
You will probably want to look into Rails’ single table inheritance
(STI) support.
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