What's your idea of designing an efficient shopping cart? 3

[asuknow]

I know some experts suggest not to store memory-consuming
object(though those objects may need to be created very frequently)in session.

Some people tend to use very few session variables for the
whole web site per user.

Shopping Cart is a very special user status, could
anyone tell me usually how do programmers store the
status of shopping cart? Do they use session to store
the whole shopping cart? Since shopping cart can be
very big (a typical cart include , I am suspecting that storing shopping cart in session can eat a lot of server
memory.

What do you guys think? What's your idea of designing
an efficient shopping cart and efficient way to update a
shopping cart?

Thanks for any tips.

 

[ToddWW]

Here's a start.

First, setup a table in your database and name it something like tempcartitems.dbf

Give it a cartid field, itemid field, quantity field, and date field.

When a visitor starts a shopping cart session, have ASP create a new Session Variable with a unique cartid number. This method will generate unique numbers for you. Make sure your cartid field in your tempcaritems.dbf can hold at least 25 characters to accept this example.

<%
Session(&quot;cartid&quot = Right(Cstr(Session.SessionID),4) & Cstr(Month(Now)) & Cstr(Day(Now)) & Cstr(timer)
%>

Now, when the visitor adds an item to the cart, insert that record into the tempcartitems.dbf making sure to supply the Session(&quot;cartid&quot and the current date along with the itemid and the number of items they have requested.

When you want to display the cart items on another page, just query tempcartitems.dbf where cartid = Session(&quot;cartid&quot.

If the user completes the transaction, have ASP delete the items from tempcartitems.dbf to keep that table as small as possible. Inevitably, visitors are going to add items to carts and bail out without completing their shopping spree.

Then, from time to time, run a maintenance script on the table that will delete from tempcartitems.dbf where date < currentdate.

Hope this gets you going in the right direction. Let me know if you need some more specific examples with ASP code.

TW

 

[asuknow]

Thank you for your detailed description.

So the major feature of your design is to use
a table in a database as a termpory storage space
for shopping cart status,
which means everytime an item is added to the shopping
cart, there will be an operation of INSERTION into
that databse, and everytime the database is updated,
there will be an VALIDATION of availability of that
item (in case the user order too many of an item) and
an UPDATING of the shopping cart table.

Question1:
Do you design a separate database for the shopping
cart table or just add the cart table to the inventory
database?

Question2:
As long as the VALIDATION is involved, this means there
will be TWO times to create a RS or COMMAND object, ONE
for opening the shopping cart table, THE OTHER for
comparing the requested quantity of each item with
the amount of item in stock.
If there are many different items in the shopping cart
table, everytime the cart needs to be updated, there
will be repetitive operations of VALIDATION, which may
make the updating of a shopping cart a very time-consuming
process.

I have not actually tested your design yet, maybe it will
run fast when I test it. What's your comments on my
comments above? Hope to hear more ideas from you guys.

Thanks again!

 

[ToddWW]

Answer #1: You will absolutely want to just add a table to the same database that the inventory table is in.

Answer #2: It's hard for me to answer the second question because I don't know your vision for the screen layout of your shopping cart. And although that doesn't sound like it has anything to do with validation, it very much plays a big role.

Is there a public website that has a shopping cart that is similar to what you are trying to design. Some sites have what looks like an order form where you can fill in quantity, select items from a list, and add many items to the cart at once. Other sites have means for you to navigate and learn about one single item on a page, then allow you to provide quantity and click &quot;Add to Shopping Cart&quot;. Other sites may have multiple items on a single page where you can add quantity to one or many of those items then click &quot;Add to Shopping Cart&quot;.

My question to you is, which one, or combination of, the examples above best describes your shopping cart ??

Most shopping cart sites use the same method when it comes to checking out or showing the shopping cart. Usually a button that displays all of the items, allows changes of quantities, and a button to complete the order or return to shopping.

There's one little quirk when it comes to validating item quantities. And that's at what point do you want to tell the visitor that there is not enough in stock for their request. Most sites will display &quot;In Stock&quot; next to the item before the visitor even adds it to the cart. The tricky part comes if you have 100 visitors on your site and all 100 want to purchase widget #1. Only you have just 50 in stock. The $1M question is, when do you want to remove the item from being available to another buyer. At the time it's added to a shopping cart, or at the time the order is confirmed. If you're OK with the &quot;at the time the order is confirmed&quot;, then things are going to get easy. However, if you want to track item availability and inventory during the shopping cart session, that could provide some challenges. Let me explain. You have 1 Reggie Jackson baseball card left. Two people get on your site at the same time. Person #1 adds the Reggie Jackson card to their cart. Person #2 tries to add it to their cart, but your site is validating during the shopping cart session and tells Person #2 Sorry, No Can Do!!. Now Person #1 just realized that he is late for a lunch appointment, closes his browser window (which is an event you won't be able to track with any degree of efficiency or certainty) and heads out the door. Now, you just lost a sale to Person #2.

In my opinion, when it comes to validating item availability in a shopping cart, you display the item availability to the visitor at the time they add it to the cart. Then, you don't recheck until that user confirms the order, at which time you can remove it from availibility in your database. Let me know if that's more down the road you're looking at.

I would love to help you out with this if you can give a few more details about the design and mechanics of your shopping cart. An example from a public website would be helpful as well.

Happy Shopping

ToddWW

 

[asuknow]

Thanks a lot for your reply.

My design of shopping cart has multiple items on a single page where users can add one or more pieces of each item to
the shopping cart.

When it comes to validation of stock availability, if
used#1 add item#1 to his shopping cart, that will not
affect the quantity of item#1 in the database until user#1
really place the order, this is not because it will
make programming easier, but because to me, if an item
is not actually purchased, it should be available.

To me, adding items to shopping cart is pretty much
the same with updating, in which validation of stock
availability and updating cart are operated.

It comes to my mind that if a temporary table is created
to store shopping cart, then how temporary should it be?
Use the lifetime of a session or the expiry date of a
cookie to judge the lifetime of a shopping cart or any other
methods?

Besides creating an temporary tables for storing shopping
cart, do you have any other ideas of storing shopping
cart?

Thank you for your very patient and detailed explanation.

 

[ToddWW]

Actually, my idea was a permanent table that would hold temporary records. So you'll create the table now and it will be there permanently. When a user adds an item to their shopping cart, you insert that item into the table along with their SessionID.

And, yes, you could write a few lines in your global.asa to remove items from the shopping cart table at the end of the session. Of course, you would also remove items from the shopping cart upon confirmation of the order.

The single shopping cart table could hold items from hundreds or thousands of visitors at any given time. There would be one field in that table that will hold the SessionID generated by IIS. The visitor will have that SessionID persisting with them throughout their session. So when it comes time to add to, update or show items in a shopping cart, you would write SQL to gather or update where the sessionIDfield = Session(&quot;sessionID&quot.. So to speak..

You set your session timeout either directly in IIS or you can set it with code. I prefer to set it in IIS then change it with code, only if necessary. A good session timeout for a shopping cart site could be 30 minutes. That all depends on how many visitors you expect to have at one time because sessions take up memory. Remember, sessions in ASP don't timeout from the moment the session starts. They timeout from the moment of non-activity. So as long as a visitor kept requesting pages on your site, they could keep a session open indefinitely. But if they go 30 minutes without requesting a page, the session expires and in your case, could execute code in the global.asa file to empty their shopping cart from the table.

You would examine a session variable at the top of every page and if it is not present, redirect the visitor to a page explaining the timeout.

So, we're going to have a permanent table (not a temporary table... Sorry :-() that can hold shopping cart items from many users at once. We want to keep that table as small as possible so we only want to store information relative to the addition of an item. What comes to my mind are the sessionID field, the itemID field, and the Quantity. When you want to display the data, you can relate the shopping cart table with the inventory table to display all of the pertinent data about the item in the cart.

Let's continue communication via email. You can reach me at todd@fuelaccess.com

That way, we can let this post move it's way down the list.

ToddWW

 

[objuan]

ToddWW,

Your explanation has been very helpful! I had a couple of questions on your recommendation. I was wondering why you suggest using an &quot;altered&quot; session identifier rather than the straight Session.SessionID from IIS. Is this to make absolutely sure that you don't have a duplicate SessionID...say in the case of a restart of IIS? Also, what do you think about doing both a temp table for shopping cart items that you would clean out if there are items in there from a shopper that did not check out, and a separate Items Ordered table where items in the temp table would be moved upon check out so you can refer back to them based on an Order ID.

I've been reading up on the use of Session Variables vs. Cookies and ran across the discussion in another thread called Cookies & Session issues in IE6. Sorry I don't know how to point to it directly, but it is an FAQ and usually at the top of the list on a Forum Search for Cookies. I was wondering if the settings in IE6 that allow you to turn off Session variables would impact the use of the SessionID.

Thanks for your detailed explanation...it helped me a lot!!!

 

[onpnt]

yes and this should explain alittle for you
faq333-2381

ps: just under the subject line you should see this
thread333-149817 ... (or in a FAQ) faq333-2381 , this is how you link to a FAQ or Thread. ---------------------------------------
{ str = &quot;sleep is good for you. sleep gives you the energy you need to function&quot;;
ptr = /sleep/gi;Nstr = str.replace(ptr,&quot;coffee&quot;alert(Nstr); }
---------------------------------------
for the best results to your questions: FAQ333-2924

http://www.onpntwebdesigns.com