Product option variations - Let the permutations begin!

[AffiliateDreamer]

Product Options - How many permutations are there?

1. Simple product, no variations.
Example: Hat

2. Variations on size and color

Example:
Shoes, comes in black and white and sizes 6,7,8,9,10,11,12

What other product variations are out there? (ones that you are currently are using or have seen)

[philbish]

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:

Color
10000K
12000K
14000K
2700K to 3000K
3300K
4000K
4500K to 5000K
6 Meter Sample
6000K
6500K
8000K
Amber
Aqua
Black
Blue
Blue/Amber
Blue/Blue
Blue/Clear
Brown
Clear/Clear
Cool White (6500K)
Gray
Green
Million
Neo-blue
Neutral White (4500K to 5000K)
Orange
Orange Cream
Pink
Plain
Purple
Red
Red/Amber
Red/Blue
Red/Clear
Red/Red
RGB (single only)
Silver
UV
Warm White
Warm White (2700K to 3000K)
White
Yellow

Size
0 Gauge
1 Foot
1.2"
1/2"
1/4"
10 Amp
10 Gauge
10" x 2"
10mm
12"
120mm
128mm
146mm
15 Amp
150 Ohm
16 Gauge
16 LED
19"
2 Amp
2 Foot
2.4"
20 Amp
20" x 4"
24"
25 Amp
25 LED
28"
2XL
3 Amp
3 Foot
3.25 Amp
36"
38"
390 Ohm
3mm
3XL
4 Foot
4 Gauge
4"
4.7"
40" x 6"
470 Ohm
48"
49 Inch
5 Amp
5" x 1"
5.5"
50 Inch
560 Ohm
5mm
6 Foot
60 Inch
7.5 Amp
70mm
8 Gauge
80mm
880/881
9.5"
9004
9005
9006
9007
ATC
H1
H10
H11
H13
H3
H4/9003
H4/9003 Bi-Xenon
H7
Large
Medium
Mini
Small
XL

Style
(+) PPT
(-) NPT
1/2"
1/4"
120 degree
25 degree
2way
4way
70 degree
Amber LED
Amber LED Independent
Blue LED
Chrome
Dome
Green LED
Long "Bat" Handle
Momentary
On / Off
On / Off / On
Pink LED
Plain - No LED
Plastic
Red
Red LED
Red w/ White LED
Regular
Round
Sealed
Short Handle
Smoked
Straight
White LED
With IR control
Without IR control

Scent
Cherry
Citrus
Coconut
Green Apple
Jasmine
Leather
Lemon Lime
New Car
Pina Colada
Pine Fresh
Vanilla
Watermelon

[hippypink]

option group 1 x option group 2 x option group 3 x etc...

e.g.

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.

[AffiliateDreamer]

On a side note, internally do you create a new SKU for each option?

[jsinger]

What's the point of this thread?

Don't forget Tall, Grande and Venti. I wear Venti shoes.

[AffiliateDreamer]

I am coding an ecommerce application so I wanted to make sure I am covering all the options (within reason ofcourse).

[lorax]

>> 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.

[AffiliateDreamer]

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.

[sja65]

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.

[lorax]

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.

[Easy_Coder]

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

[AffiliateDreamer]

EasyCoder,

I guess where it gets complicated is where you can only a certain number of sizes per color or width or both!

[Peat]

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!

[Easy_Coder]

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
1 White
2 Navy

Types which really aren't required unless you're planning on selling European or Middle Eastern style shoes translates like this

typeid ¦ type
1 US
2 Euro

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.

[rocknbil]

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.

[Easy_Coder]

Would the material be the same across all variations of a given sku?

[rocknbil]

Maybe. Or maybe not. :-) That's the problem.

[Easy_Coder]

Then you would need to treat it with the dimension of sku, size, width color, type material etc... versus a single level attribute.

[rocknbil]

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.