NYCPHP Meetup

[Randal Rust]

csnyder wrote:

> Since you're right about the session going away, you'll need to use a
> database to store the items, 

good. that's what we're doing anyway. no javascript, no over-the-top 
session stuff.

> under an id that you can put into a
> cookie for when they come back. The items aren't stored in the cookie,
> only the reference to the cart.

so i could randomly generate a 6-10 digit id for the cart. would that be 
the way to go?

> A bonus to this approach is that you can also mark the cart with a
> userid, so that if they start shopping from home, but then log in at
> work to complete the transaction, they can pick up where they left
> off.

right, there is a customerID column in the table. but you've got me 
thinking that there should be a 'cart' table, which stores the cartID 
and customerID. it would tie to the 'orders' table, which would hold the 
orderID, cartID, etc.

so each user would have their own unique cart. would that be overkill?

every time someone access the site, i'd have to check for the cookie. if 
it exists, then we're ok, the user already has a cart created. if the 
cookie does not exist, then a new row has to be created in the cart 
table, which provides the unique id for the customer's cart. this would 
avoid having to randomly generate a number.

-- 
Randal Rust

R.Squared Communications
http://www.r2communications.com
Digital Design for Bricks-and-Mortar Businesses