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.
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
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
[email protected]