I am trying to design database for a simple online shopping cart.I am not getting the idea of what to place for the table shopping cart.Is not it ok to create cart id as primary key?And later on while updating the items in a cart,what would be the appropriate logic to update only the changed field(say quantity) of a particular product?Please help me on this.
A:
An artificial PK (such as cartID, an auto-increment integer PRIMARY KEY) is almost always "just fine" (and I don't see why a table of shopping carts should be any different in this regard from others). As for your other question -- what indication do you have of what fields were changed? Why would it be any problem at all to UPDATE the table with every field, including those that weren't changed?
Alex Martelli
2009-06-15 05:41:00
A:
My answer was completely wrong, i got 2 ideas mixed up. I've erased it so it doesn't confuse anyone.
Galen
2009-06-15 05:48:12
A cart and an order are not related in this way. A cart references current products, whereas an order is historical. e.g an order can still exist (for reporting etc) once the product goes out of stock or even if it is deleted. A cart contains references to 'products' and an order contains 'lineItems'
David Archer
2009-06-15 09:29:59
you're right i got order_item mixed with cart. thanks
Galen
2009-06-15 10:33:58
A:
Don't store your cart information in the database, you don't want to be making an UPDATE query every-time someone adds something to their cart or alters the quantity.
Use a session to keep an array of item numbers (ref the database ids of the items) and their quantity.
When the user is ready to 'checkout' just pull the item details from your session and build an 'order'.
Luke Antins
2009-07-13 14:38:52