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? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 30 September 2010 13:17, Christian Fazzini <christian.fazzini-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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? On Sep 30, 8:29 pm, Michael Pavling <pavl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 30 September 2010 13:17, Christian Fazzini > > <christian.fazz...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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?-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Christian Fazzini 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 marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Marnen, in this case, what would you rather use? STI or polymorphism? On Sep 30, 11:13 pm, Marnen Laibow-Koser <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Christian Fazzini 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-Koserhttp://www.marnen.org > mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org > -- > Posted viahttp://www.ruby-forum.com/.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Please quote when replying. Christian Fazzini 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 marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.