Curious about the best direction or design pattern to use here - looking for opinions. I have a store with products diced into categories. Should I create a polymorphic model ''Product'' and have individual models for the product types? Reason is - the products differ quite a bit in columns/profile etc... I could keep in one table but feel it will get horizontally fat quickly as these different product types get modified. Question is - I''ll need to access these different products so would I simply delegate attributes to the Product model so I can access each related model''s attributes? For instance, I''ll need to fetch all of a certain type through the Product model. I guess I could use STI for this but seems polymorphic would perform better. Appreciate any feedback on whether this is practical or way off. -- 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.
Hi Randy, Hard to say for sure without knowing the specific needs/requirements/ demands of your app, but ... if your app is a typical biz or ecomm app backed by an rdbms where most of the usage (for end users and for analysis) of the app is spent doing reads vs writes, when it comes to the design of the db, ime, regardless of caching strategy, I always try and error on the side of faster reads (and slower writes) vs faster writes (and slower reads). So, assuming a read-dominent app, if you''re asking "should I go with one table for all products, or one table per product type?", if I were the developer, I''d probably go with the one (wide/sparse) table strategy. I''d define/handle the different needs/rules of the various product types in app model(s) code, but have the Product model ob handle core persistence of all of those various types of products (stored in the products db table). The less round trips to the db, the less joins in the db, the more denormalized the db, the more indexed the db, ... all of these should help make direct db reads faster (at the cost of slower writes on such wide/sparse/denormalized tables). Jeff On Dec 6, 9:50 pm, Randy Clark <ra...-3lAQYOrn1V5BDgjK7y7TUQ@public.gmane.org> wrote:> Curious about the best direction or design pattern to use here - > looking for opinions. > > I have a store with products diced into categories. Should I create a > polymorphic model ''Product'' and have individual models for the product > types? Reason is - the products differ quite a bit in columns/profile > etc... I could keep in one table but feel it will get horizontally fat > quickly as these different product types get modified. > > Question is - I''ll need to access these different products so would I > simply delegate attributes to the Product model so I can access each > related model''s attributes? For instance, I''ll need to fetch all of a > certain type through the Product model. > > I guess I could use STI for this but seems polymorphic would perform > better. > > Appreciate any feedback on whether this is practical or way off.-- 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.
Randy Clark wrote in post #966805:> Curious about the best direction or design pattern to use here - > looking for opinions. > > I have a store with products diced into categories. Should I create a > polymorphic model ''Product'' and have individual models for the product > types? Reason is - the products differ quite a bit in columns/profile > etc...Do the simplest thing that could possibly work. Right now, that would probably be one product table, unless you *already* have different information to store for different product types.> I could keep in one table but feel it will get horizontally fat > quickly as these different product types get modified."I feel" is usually not a great justification. Design for what you have now, not what you might have. If you start ending up with a lot of divergent data, refactor at that time.> > Question is - I''ll need to access these different products so would I > simply delegate attributes to the Product model so I can access each > related model''s attributes? For instance, I''ll need to fetch all of a > certain type through the Product model. > > I guess I could use STI for this but seems polymorphic would perform > better.Or perhaps something similar to Jeff''s suggestion: have a products table with core information, but a has_one relationship to other records as needed. Or (last resort) a serialized hash of additional attributes.> > Appreciate any feedback on whether this is practical or way off.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.