Shopping Cart

I'm working on a project that will include a shopping cart. I was considering creating my own and then thought twice. Some of the issues that troubled me were: An items table with all the different sizes, colors, formats, etc. What king of table design would I use for this? Also, how would I code it in a class that would make it somewhat easy to implement.
Any suggestions out there? I was looking at .netCart and it seems to be a good product. Of course, I'm working with 2.0 and I'm not sure if that supports 2.0
Any other ideas for either implemeting a cart system or a prepackaged one? From what I can see, for $300 or so, how much time would creating a good cart system take and is it worth it?

Hello.
Maybe you can represent your items as a class and build your own list which is kept by using profiles.

That's my thought, and I've read plenty on it and I'm confident I can implement.
My biggest question is how do most folks handle the same item with multiple variations (color, size, etc) as far as the DB is concerned.
Hello snaayk,
here you can findfour ways of how implement a shopping cart. Hopes this helps.
Thanks, ByReckon, but I read that - actually they're all good articles.
My issue is this (and I might need to post in a sql type forum) I have a DB with the following tables:

Customer
Order
OrderItems
Items

I'm sure we all understand the relationship between the four. My issue is with items. Which might contain some columns like:

ItemId, ItemPrice, ItemQuantityType, ItemInStock, ItemStockQuantity, ItemSku, ItemLongDescription, ItemShortDescription

Now, Let's pretend you're at www.gap.com, and you want to buy some jeans and a t-shirt. When you order you have the following type of choices

Size
Color
Width
Length

Even worse is that not ever item has the same option - the t-shirt does not contain an option for inseam. How does one do this part of the database and the cart. I noticed that the .netCart includes the infrastructure ro do this - how did they do it?

One way to solve your problem would be to have a Properties table that is joined to the Item table in a many-to-many relationship by an intermediate table called ItemProperties. So in the Properties table you would have things like Color, Inseam, Size etc. and then have another table to store the values for a particular Item/Property combination. This approach is somewhat bulky but it should work just fine. You could cut out the Properties table and just have the ItemProperties and ItemPropertyValues table but that would mean that properties could not be shared.

Hope this helps.

Thnaks CallMeLee. I was thinking along these lines as well. It's definately bulky, but it will work.
Any other ideas, anyone?