# Architectural question: one model, different properties

**URL:** <https://www.ruby-forum.com/t/architectural-question-one-model-different-properties/69764>\
**Category:** Rails\
**Created:** [September 23, 2006, 11:30pm UTC](https://www.ruby-forum.com/t/architectural-question-one-model-different-properties/69764 "2006-09-23T23:30:04Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Elektroholunder](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ecccb3/32.png) [@Elektroholunder](https://www.ruby-forum.com/u/Elektroholunder)\
**Post date:** [September 23, 2006, 11:30pm UTC](https://www.ruby-forum.com/t/architectural-question-one-model-different-properties/69764/1 "2006-09-23T23:30:04Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Elektroholunder](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ecccb3/32.png) [@Elektroholunder](https://www.ruby-forum.com/u/Elektroholunder)\
**Post date:** [September 24, 2006, 3:19pm UTC](https://www.ruby-forum.com/t/architectural-question-one-model-different-properties/69764/2 "2006-09-24T15:19:48Z")

</div>

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](http://www.thebootstrapnation.com)

---

<div class="post-metadata">

**Author:** ![Elektroholunder](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ecccb3/32.png) [@Elektroholunder](https://www.ruby-forum.com/u/Elektroholunder)\
**Post date:** [September 24, 2006, 4:19pm UTC](https://www.ruby-forum.com/t/architectural-question-one-model-different-properties/69764/3 "2006-09-24T16:19:13Z")

</div>

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.

- Roderick

---

<div class="post-metadata">

**Author:** ![Elektroholunder](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/e/ecccb3/32.png) [@Elektroholunder](https://www.ruby-forum.com/u/Elektroholunder)\
**Post date:** [September 24, 2006, 6:32pm UTC](https://www.ruby-forum.com/t/architectural-question-one-model-different-properties/69764/4 "2006-09-24T18:32:06Z")

</div>

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