Selling Tshirts Purchasing All Sizes

[caucus]

Hello

I just got your book from Amazon and love every bit of of it.

 

I have seen this done before and what I would like to do is give the customer the ability to purchase any and all sizes of shirts I have in stock

 

1. I have one blue T-shirt in sizes S - M - L - XL - 2XL

 

2. I need to show how many of each I have in stock

 

3. The customer can purchase as many of the sizes I have in stock

 

4. The key here is displaying all the sizes with quantity in stock and letting the customer purchase all the sizes she wants at one time.

 

Thanks and I hope someone can help or show me a tutorial so I can make this happen.

 

At check out it will show all the different sizes that were bought and how many. And of course 2XL may cost $4 more than other sizes.

 

 

Thanks again for a great book and hope somebody can help me out.

[Larry]

Thanks for the nice words on the book. It is appreciated. What you're asking about is a good question, as it's common enough, but is complicated. The trick as I stress in the book is that you need unique identifiers to set prices and quantities and orders and such. But you also need to be able to easily reflect available colors, sizes, and so forth.

 

There are a couple of ways of going about it and how you approach it depends upon all of the details of your particular site. If you're just selling shirts, it's a bit easier...

 

Start with a sizes table (size_id, size), a colors table (color_id, color), and a general_shirts table (name, description, other generic information). Then you'd create a specific_shirts table: specific_shirt_id, general_shirt_id, size_id, color_id, price, quantity. That gets you what you need. If the structure looks familiar, that's because it's essentially the same thing that the book does with variations on coffee.

[theaceofthespade]

I came on with a similar question. First off, amazing book!! I'm working on a website for overstocked goods. The option sets for various products are unpredictable, so simply creating an outright table for the options is not viable (one product my be a shirt in multiple sizes, another mite be a blanket with various thread counts, etc). Either way, it has to keep track of the options, and each options stock.

 

First, I thought to do a table for the options - each product would link to an option group (or vice versa), and each option in the options table would have a name, a price, an sku modifier, and a stock amount. That way, if you had a shirt, you could link it to the options small, medium, and large, with their various data, and if you had a sheet, you could link it to its various thread counts, and it could all be held within the same table.

 

This is the only way I've come up with to solve the issue. I was also considering just making a serialized php array, but that's something I try to avoid no matter what, so for now I'm left with the above solution. Am I on the right track here? Any advice?

[Larry]

Thanks for the nice words on the book. It is appreciated. As for your situation, you're correct in thinking that it's complicated and you are moving in the right direction. One option is to create a table for each product type that would have similar options: shirts, sheets, etc. This is easy to do, but makes less sense the more varied the products get.

 

To be more generic, you'll need to create many tables to do this right:

option_types: option_id, option_type (size, color, thread_count, etc.)

option_values: option_value_id, option_type_id, value (Medium, Large, Blue, Red, 300, 400, etc.)

products_options: product_option_id, product_id, option_value_id [You could do a composite primary key instead on the combination of product_id and option_value_id]

 

Then your products table needs a product ID, price, and quantity. This completes the association of products with options.

 

You may want to do a general_products table with common data (manufacturer, description, etc.), then do a specific_products that stores the price and quantity and links to the products_options.

[theaceofthespade]

Again, sorry for the lack of response. So I wound up going a simpler route, although there is certainly not perfect from a design standpoint.

 

Basically, I decided that I was going to force each product to have only one set of options. If the product has more than one set, then it just needs to be split into products. From there, I just made an option table, forced all products to automatically have one product_option, and then set it so that the name of the options was stored in the product table.

 

So for tshirt sizes, there would be the product options "large","medium","small", each with their own price and stock data. Then the product row that they were all linked to would have the "option_name" column set to "Shirt Size"

 

It's one of those solutions where I'm happy with how simple it is, but at the same time know that it pays for that simplicity with expandability. there is a forseeable circumstance where limiting myself to the single option set is not optimal.

[Larry]

Thanks for the update. I'm a pragmatist, so I do differentiate between what one SHOULD do and what one WILL do. I'm never opposed to cutting corners so long as you're purposefully doing so. It's the times that people make "non optimal" decisions without being cognizant of the consequences that I think is problematic.