Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: buckworks
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
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.
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!
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.
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.
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.