Re: Database Design for Shopping Cart

Hmm, I would expect there to be other details associated with the shopping cart also. For example, you might have a Date Created so that you can clean out abandoned carts after a certain period of time?

I think normalisation does require you to have a Shopping Cart table, even if there is very little information associated with it. This will also keep you database design open to change.

Just out of interest, what will happen when the user decides to create an Order based on the contents of the cart? Will you create separate order/lineitem tables. Or, are you using the Cart entity to represent both orders and shopping carts? What do you think is best here?

Tobin Harris

"Art" <ashannon_at_sfsu.edu> wrote in message news:U0qD8.1004$1s3.58136625_at_newssvr21.news.prodigy.com...
> I designed one and it has one shoppingcart table that contains only one
> field, UserID, which I feel weird. It looks like this:
>
> tblShoppingCart tblCartDetail
> tblProduct
> UserID * ------------------------------>UserID *
> ProductID
> * ------------------------------------>ProductID *
>
> (also have other fields)
> (* is for primary key)
>
> Could anyone please give me a suggestion?
>
> Thank you
>
>
Received on Sun May 12 2002 - 12:49:21 CEST