Is STI the right way here?

I want to store information about links, podcasts, blogs, wikis …

Each item will have a link, user_id, created_at, headline,
description… additional a podcast item will have fields like
filetype_id, duration, mb…, blogs will have a additional field
like audience…

So my intention is to make a big table with the type field and use
STI.

Is this the recommended way to store such data or is there a more
elegant way to solve this?

Thanx

why not a polimorphic association?

Jochen K. wrote:

I want to store information about links, podcasts, blogs, wikis …

Each item will have a link, user_id, created_at, headline,
description… additional a podcast item will have fields like
filetype_id, duration, mb…, blogs will have a additional field
like audience…

So my intention is to make a big table with the type field and use
STI.

Is this the recommended way to store such data or is there a more
elegant way to solve this?

If you can manage to fairly narrowly define which columns you’ll need up
front then I do think that STI would be the best option here. After all,
it’s all content plus a couple of extras here and there.

An important operative word in polymorphic associations [1] is
“associations”. You could model it such that you have a generalized and
polymorphic association called something like “content”, but when you
look at it from a functional perspective it really isn’t that much of an
association at all – it’s contained within the same object. The point
I’m trying to make here is that I think that using polymorphic
associations would be a bit of a stretch to make it happen.

So in all: STI is a safe bet and seems fit for use in this case.

[1]
http://wiki.rubyonrails.org/rails/pages/UnderstandingPolymorphicAssociations


Roderick van Domburg
http://www.nedforce.nl

Raffaele Tesi schrieb:

why not a polimorphic association?

?? Never heard of this…


Jochen K.
railswerk.de, gissmoh.de, figgfrosch.de, ror-ror.de

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs