Im going to build simple cart system(with list of chosen product, modifying product quantity).
Im wondering using session with array, is that the right way?
Any advice?
Thanks
Session Based Shopping Cart
Moderator: General Moderators
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Re: Session Based Shopping Cart
That should work just fine, just keep the data that you store in the array to a minimum and pretty simple. For example, an array of product id's, and on each page load, you'd build the cart by looking up the id's in the database.
Rather than using session's, data like that might be more appropriately stored in cookies. This will allow you to expire the session, but retain the user's shopping cart for a longer period of time.
Rather than using session's, data like that might be more appropriately stored in cookies. This will allow you to expire the session, but retain the user's shopping cart for a longer period of time.
Re: Session Based Shopping Cart
I have been thinking of using cookies but since Im new in PHP, I would rather choose easier way, session.
What about changing the item quantity, process is done before storing data to database right?
What about changing the item quantity, process is done before storing data to database right?
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Re: Session Based Shopping Cart
Neither method is easier or more difficult than the other. Sessions are typically based on cookies.
This is how I believe shopping carts should operate, but this is more or less dependant on your design.
You will have 2 types of users, those who are registered with an account, and those who are not (guests). Generally sessions are cookie based and you would use sessions to track and authenticate users. You can store cart data in sessions, but sessions typically expire when you close your browser window. This means, if I add pork chops to my shopping cart and close the window, the next time I visit your site, my pork chops are gone from my cart because my session expired. However, if you store my cart in a cookie and set the lifetime of the cookie to something like 30 days, then my pork chops will still be in my cart on my next visit.
Its up to you, the major difference between cookies and session is where the data is stored.
Changing item quantity on what? On items in my cart? I thought you were storing the cart in a session, so you shouldnt need to update the database, just update the session data. If you mean changing item quantity to decrement your inventory on hand when I buy something, then a SQL transaction is probably your best bet.
This is how I believe shopping carts should operate, but this is more or less dependant on your design.
You will have 2 types of users, those who are registered with an account, and those who are not (guests). Generally sessions are cookie based and you would use sessions to track and authenticate users. You can store cart data in sessions, but sessions typically expire when you close your browser window. This means, if I add pork chops to my shopping cart and close the window, the next time I visit your site, my pork chops are gone from my cart because my session expired. However, if you store my cart in a cookie and set the lifetime of the cookie to something like 30 days, then my pork chops will still be in my cart on my next visit.
Its up to you, the major difference between cookies and session is where the data is stored.
Changing item quantity on what? On items in my cart? I thought you were storing the cart in a session, so you shouldnt need to update the database, just update the session data. If you mean changing item quantity to decrement your inventory on hand when I buy something, then a SQL transaction is probably your best bet.
Re: Session Based Shopping Cart
What about storing item in cart into database, I want to make table to store all order, but item in cart is more than one, I dont know how to put multi value in one field.
This is my Order Table example:
[text]
order_id | order_user | order_item | order_qty
--------------------------------------------------------
001 | John | prod1, prod2 | 3
002 | Mike | prod3, prod4 | 5
-------------------------------------------------------
[/text]
That is all I can imagine, is that correct?
This is my Order Table example:
[text]
order_id | order_user | order_item | order_qty
--------------------------------------------------------
001 | John | prod1, prod2 | 3
002 | Mike | prod3, prod4 | 5
-------------------------------------------------------
[/text]
That is all I can imagine, is that correct?
- flying_circus
- Forum Regular
- Posts: 732
- Joined: Wed Mar 05, 2008 10:23 pm
- Location: Sunriver, OR
Re: Session Based Shopping Cart
Ok, I think I see what you are after. Create 2 tables. The first table contains unique order details, such as the order number, customer name, address, etc. The second table will store the items for each order.
table 1:
- Order Id
- Customer Name
- Address
table 2:
- Order Id
- Item Id
- Item Quantity
The two tables are linked based on "Order Id", so that is how you determine which items belong with each order.
table 1:
- Order Id
- Customer Name
- Address
table 2:
- Order Id
- Item Id
- Item Quantity
The two tables are linked based on "Order Id", so that is how you determine which items belong with each order.
Re: Session Based Shopping Cart
Yes, that's what I mean, I never thought of create two table for order, thanks.
Re: Session Based Shopping Cart
I've done this once (for a pretty basic simple shop) by simply having one 'items' field in the order table, and storing values like 'productA,productB,productC' there. Or '2,productA,3,productX' meaning 2 units of productA and 3 units of productX.
SQL purists probably feel uncomfortable by this approach, but for my purpose in this situation it worked perfectly and was very simple and convenient to work with. Some implode and explode calls were easier in this case than combining results of several SQL queries.
SQL purists probably feel uncomfortable by this approach, but for my purpose in this situation it worked perfectly and was very simple and convenient to work with. Some implode and explode calls were easier in this case than combining results of several SQL queries.