Model: Product Attributes
schof
OSCommerce (http://svn.oscommerce.com/fisheye/browse/~raw,r=1659/
osCommerce/oscommerce2/trunk/extras/tep_database-pr2.2-CVS.pdf) So
far I'm only focusing on the product stuff. It looks like pretty much
how I envisioned things but it still leaves one important questions
(regarding product attributes) unanswered: How do we handle
inventory?
Suppose you are selling t-shirts and you have a size attribute (S, M,
L, XL) and a color attribute (Red, Green, Blue, Black, White). Does
each combination have its own SKU? Wouldn't you want to track
inventory for each of these combinations? This could probably be
handled by a couple of inventory related tables. What do you think?
JAWspeak
Glad to see you get this started up and the emails off of the private
thread. I'm excited about the prospects of this project.
We could create attributes that attach to every product. And admins
could even create arbitrary different kinds of attributes (besides
just color... maybe someone would want different arbitrary units of
measure.) Yet, thinking along the Tracer Bullet style of the Pragmatic
Programmers, this is probably something that can be refactored once we
have a first-pass working app. http://www.artima.com/intv/tracer2.html
I'd keep it as simple as we can at first,
jaw
snacktime
is happy. With shipping being a close second. The majority of
companies do keep separate sku's for different product variations.
Let's assume we want nested attributes also. So if a variation is a
product, then just represent it as a tree in one table.
table products (
id
sku
parent_sku
master_sku
on_hand
reorder_at
name,descript,price,etc..
)
So to get a product with all it's variations is one fast query on sku
= 'sku' and master_sku = 'sku'.
In the web interface you could let users either choose a sku, or just
build a sku for them based on the master sku.
Chris
schof
> could even create arbitrary different kinds of attributes (besides
> just color... maybe someone would want different arbitrary units of
> measure.) Yet, thinking along the Tracer Bullet style of the Pragmatic
> Programmers, this is probably something that can be refactored once we
> have a first-pass working app.http://www.artima.com/intv/tracer2.html
Not familiar with the term "Tracer Bullet" but I read the blurb you
cited and this sounds similar to the approach I would typically use.
> I'd keep it as simple as we can at first,
Here's what I was thinking. We already have products. For each model
class we add we should then add test cases, controllers and the usual
CRUD actions in those controllers. I'm reading up on testing with
Rails now b/c I would prefer a robust suite of unit tests to make our
refactoring efforts easier.
Now, there seems to be a couple of options about which "tracer"/test
case/whatever to pursue next.
1.) Flush out products some more (like adding attributes and
options). This way you have a robust admin tool for adding and
editing products. By the way, we could skip some of the more advanced
features like separate skus and inventory control and come back to
that later.
2.) Consider products "done" for the moment and move on to the cart
and checkout process.
I think a case can be made for either approach. I'm open to
suggestions.
Sean
schof
parent_sku and master_sku. Don't we just need on of these? (I would
suggest parent_sku.) This approach would suggest that the store owner
has two choices:
1.) No separate sku for each variation. This would probably limit
your ability to carefully monitor inventory. Perhaps that could be
partially remedied by allowing an admin to mark a variation as "out of
stock."
2.) Separate sku for each variation. We would still want a way for
the end user to see the same list of options and price effects (if
any).
I think the more sophisticated option (#2) is the most desirable but
maybe we should hold off on programming that part until we have made
more progress on some of the more basic functionality?
Sean
snacktime
>
> This sounds interesting although I can't tell the difference between
> parent_sku and master_sku. Don't we just need on of these? (I would
> suggest parent_sku.) This approach would suggest that the store owner
> has two choices:
>
the parent branch node. You don't need master_sku and parent_sku both
you can just use one column to designate a parent node. A root node
(master sku) would just have an empty parent_sku.
> 1.) No separate sku for each variation. This would probably limit
> your ability to carefully monitor inventory. Perhaps that could be
> partially remedied by allowing an admin to mark a variation as "out of
> stock."
>
> 2.) Separate sku for each variation. We would still want a way for
> the end user to see the same list of options and price effects (if
> any).
>
> I think the more sophisticated option (#2) is the most desirable but
> maybe we should hold off on programming that part until we have made
> more progress on some of the more basic functionality?
Implementing it yes, but I would design how it will work now. You
don't want to have to go back and restructure core data models at a
later time.
Chris
snacktime
> the parent branch node. You don't need master_sku and parent_sku both
> you can just use one column to designate a parent node. A root node
> (master sku) would just have an empty parent_sku.
Actually I take that back, you would want both master_sku and
parent_sku so you can get a product with all variations in one query.
Chris
schof
> don't want to have to go back and restructure core data models at a
> later time.
It should be easy to add a parent_sku to the model (at a later point)
should we decide to go in that direction.
> Chris
Sean
schof
I don't like the idea of adding a db column to improve performance or
simplify queries. In most cases wouldn't it be sufficient to assume
only one "generation" of children? So for a shirt product you would
have a bunch of children: Small Blue, Medium Blue, Large Blue, Small
Red, Medium Red, etc.
> Chris
Sean
Thomas Nichols
On Jul 23, 11:54 pm, schof <sean.schofi...@gmail.com> wrote:
[...snip...]
>
> I don't like the idea of adding a db column to improve performance or
> simplify queries. In most cases wouldn't it be sufficient to assume
> only one "generation" of children? So for a shirt product you would
> have a bunch of children: Small Blue, Medium Blue, Large Blue, Small
> Red, Medium Red, etc.
> Sean
That's all I'd need for my clients. If they get to the point that a
factorial explosion of t-shirt colors.size * styles.size *
fittings.size (or whatever) becomes an issue, they're going to have
discrete skus for each anyway so I expect to be managing that
complexity in the UI -- I probably want a picture of a blue t-shirt if
they select Blue, for example. Adding a tree structure to the schema
at this stage certainly doesn't sound like doing The Simplest Thing
That Could Possibly Work :-)
It should be easy enough to refactor to this later if it looks
worthwhile -- perhaps just use acts_as_nested_set.
Just my two penn'orth.
Thomas.
schof
Welcome to the group! I agree lets keep it simple.
Sean