Is this a good STI approach?

Rails
#1

Ive got 3 types of media. Event, photo and video.

Most of these share common columns (title, description, etc). I am
thinking of creating a 4th model called media. And then event, photo
and video will inherit from media, making media an STI.

Is this a good approach?
I am worried that since all submissions are going into one table (the
media table). Some db performance issues may arise?

What are your thoughts?

#2

On 30 September 2010 13:17, Christian F.
[email protected] wrote:

Ive got 3 types of media. Event, photo and video.

Most of these share common columns (title, description, etc). I am
thinking of creating a 4th model called media. And then event, photo
and video will inherit from media, making media an STI.

Is this a good approach?

It is an option - for me, it would depend on how much other, different
data each model has.
Your structure may also suit a polymorphic approach - so that Event,
Photo, and Video all have a “Media” association for the common fields.

I am worried that since all submissions are going into one table (the
media table). Some db performance issues may arise?

How many Media do you plan to have?.. what sort of problems do you
anticipate that you wouldn’t have with separate tables?

#3

Well its the primary nature of the site. So expect to have tons of
media types. Initially, I thought separating them would keep the
tables smaller since each media type has its own table.

Someone mentioned that having it as an STI is fine. Like any other app
that becomes huge, we can always optimize?

#4

Marnen, in this case, what would you rather use? STI or polymorphism?

#5

Christian F. wrote:

Well its the primary nature of the site. So expect to have tons of
media types. Initially, I thought separating them would keep the
tables smaller since each media type has its own table.

There’s generally no point to keeping tables smaller just for the sake
of keeping them smaller. If you have proper indices and well-designed
queries, your DB should be able to deal with large tables.

STI is perhaps smelly for other reasons (polymorphism or composition is
often preferable), but in certain cases it really is the best way of
doing things.

Someone mentioned that having it as an STI is fine. Like any other app
that becomes huge, we can always optimize?

What’s to optimize?

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

#6

Please quote when replying.

Christian F. wrote:

Marnen, in this case, what would you rather use? STI or polymorphism?

STI, polymorphism, or composition? It’s hard to tell from the
information you’ve provided. It really depends on what sort of data
your application stores and how the application is using that data.
There’s no one answer, though I admit to a bias against STI for the
reasons I gave in my previous post.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]