| 3:05 am on Jul 18, 2007 (gmt 0)|
There's only about 50 permutations
Lol, I think its unlimited/infinite
I have products and versions.
Each product is made up of at least 1 version.
When a customer orders something, it is always done at the version level. Inventory is stored at the version level, etc.
There can be single-version products (For example a universal fit hat only offered in 1 color)
Single version products do not have version type attributes.
Or there can be multi-version products.
Multi-version products can have an unlimited number of "Version Types", and "Type Values".
Verion Types = Color, Style, Size
Type Talues = red, green, blue
I store all this data in a fairly optimized relational database.
Here's mine so far:
2700K to 3000K
4500K to 5000K
6 Meter Sample
Cool White (6500K)
Neutral White (4500K to 5000K)
RGB (single only)
Warm White (2700K to 3000K)
10" x 2"
20" x 4"
40" x 6"
5" x 1"
Amber LED Independent
Long "Bat" Handle
On / Off
On / Off / On
Plain - No LED
Red w/ White LED
With IR control
Without IR control
| 12:28 am on Jul 23, 2007 (gmt 0)|
option group 1 x option group 2 x option group 3 x etc...
color: red, white , blue
size: 1, 2,
width: 1", 2", 3", 4"
in this example- 3 x 2 x 4 = 24
infinite number of combinations depending on options offered.
| 1:54 pm on Jul 23, 2007 (gmt 0)|
On a side note, internally do you create a new SKU for each option?
| 2:17 pm on Jul 23, 2007 (gmt 0)|
What's the point of this thread?
Don't forget Tall, Grande and Venti. I wear Venti shoes.
| 3:46 pm on Jul 23, 2007 (gmt 0)|
I am coding an ecommerce application so I wanted to make sure I am covering all the options (within reason ofcourse).
| 6:31 pm on Jul 23, 2007 (gmt 0)|
>> I wanted to make sure I am covering all the options
Make it easy on yourself. Let the user define the options and apply them to different classes of products as they wish.
| 7:18 pm on Jul 23, 2007 (gmt 0)|
lorax, that is exactly what I plan on doing. I just wanted to see what kinds of product options/attributes people are using so I can build that feature in.
| 12:44 pm on Jul 24, 2007 (gmt 0)|
I stock around 30,000 different products and the majority of my traffic comes from organic search engines - so, having all options on the entry page is very important. If you have a page for widgets with no other options, you can offer options for 1 widget, 12 widgets and case of 100 widgets (you would be surprised how many people go for the bulk - even for a product where you think it doesn't make sense). If you have blue and red options, you could list blue widgets, red widgets and both blue and red widgets.
It comes down to the good, better, best strategy. Some people will automatically buy the most expensive, some the cheapest, but the vast majority will take the middle option. This allows you to steer your customers away from the cheapest products while still keeping them thinking they got a good deal.
| 12:44 pm on Jul 24, 2007 (gmt 0)|
Understood but what we're talking about is OOP. You should be able to allow the user to define building blocks for their use without having to know what they are or how they will be used. All you need to do is to define some basic rules like a) you can't have two blocks with the same name, b) you cannot delete a block without first disassociating it from the products that use it, etc.
| 8:21 pm on Jul 24, 2007 (gmt 0)|
I've built a footwear system and my shoe attributes look like this:
model ¦ size ¦ color ¦ width ¦ type
model = sku
size = shoe size
color = color id
width = width of shoe
type = European or US based size
| 8:27 pm on Jul 24, 2007 (gmt 0)|
I guess where it gets complicated is where you can only a certain number of sizes per color or width or both!
| 8:32 pm on Jul 25, 2007 (gmt 0)|
I suggest avoiding calculating all of the combinations -- what your clients have to manage and what the customers see should be entirely driven by your inventory (or capabilities, if you're a manufacturer).
If you come at it from the perspective of modeling individual SKUs with variate features and values, you'll do much better in the long run!
| 8:32 pm on Jul 26, 2007 (gmt 0)|
You'd have a record for each variation AD. Kinda like this.
model ¦ size ¦ color ¦ width ¦ type
xyz 10 1 D 1
xyz 10.5 1 D 1
xyz 11 2 B 1
The color codes would map back to a Color table
colorid ¦ color
Types which really aren't required unless you're planning on selling European or Middle Eastern style shoes translates like this
typeid ¦ type
You could store translations on the sizes and widths too if you wanted but you'll be dealing with several joins to fetch the data at that point.
| 11:04 am on Jul 27, 2007 (gmt 0)|
Easy_Coder, what if down the line your customer wants to add the option "material?" (leather, vinyl, canvas . . . . )
|I am coding an ecommerce application so I wanted to make sure I am covering all the options (within reason of course). |
When I first saw this thread I thought that was exactly why you were asking but thought I'd wait it out. :-) There is no way to keep this "within reason" if you wish to have it used by anyone. Unless of course, you know everything anyone will ever sell in the future.
This opens a good question, one I've grappled with a bit. My solution was to create an options table as follows:
rec_id product_id option_name option_value sku required price active
There are other fields of course, but these are the basics. The Achilles heel of this approach is that the option name must be identical for all applicable options, or you get two options to select from for any given product_id: there should only be one option "Color", not "color" and "Color". This makes my approach slightly vulnerable to user error, but it should become obvious to the user when they see a select list for both "color" and "Color" in the product display.
The advantage is you don't care what the option names or values will be. The option name and value can be anything at all. It allows you to set different prices for options (example, small, medium, and large), which would override the base price of product_id if the option is required, or add to the base price if it is not required (option: "spare shoelaces", required=0.) Active allows you to stop offering an option, but not mess up any orders placed with this option - if you simply delete it, you won't be able to view old orders intact. SKU is strictly optional but helpful: 0199S, 0199M, and 0199L.
It will be interesting to explore the logic some of you use in approaching option management.
| 1:03 pm on Jul 27, 2007 (gmt 0)|
Would the material be the same across all variations of a given sku?
| 6:15 pm on Jul 27, 2007 (gmt 0)|
Maybe. Or maybe not. :-) That's the problem.
| 8:09 pm on Jul 27, 2007 (gmt 0)|
Then you would need to treat it with the dimension of sku, size, width color, type material etc... versus a single level attribute.
| 7:07 pm on Jul 28, 2007 (gmt 0)|
This is why I asked the question. You get the thing built, your options are hard-coded, database fields created, then get a call in a few months, "we need to add material." A few months later, a different option. Or an option that is dependent on other options . . . see where I'm going?
While a programmer may see this as "job security" a site owner is likely to see it as an annoyance. By making your options table generic, the site owner can add and remove options of their choosing any time they want without re-programming the thing. It also makes it much easier to port to other applications besides shoes.