in reply to Re^2: Code Design Issues
in thread Code Design Issues

To answer and clarify some things:

I am saving my sessionid's on File at the moment. Thanks for good input on database calls.

However, I think you missunderstood what I meant with a shopping cart

A shopping cart is a TEMPORARY storage place where my customers put information on objects they are planning to buy.
When they are done shopping they will checkout their objects, they will receive an orderreceipt.
Relations between customer and shopping cart will be deleted.
They also have a choise of not going to the checkout, in that case relations between customer and shopping cart will be deleted.

So what information am I intrested in at the moment or will be in the future.

I already have information on my products, I store that in my PRODUCTS table
I want information on my customer, I store that in my CUSTOMER table when the customer checkout
I want information on what my customer bought, I store that in my ORDER table

Do I really want information on what products my customers put in their temporary shopping carts, products that at the end, won't be bought?

Replies are listed 'Best First'.
Re^4: Code Design Issues
by dragonchild (Archbishop) on Feb 07, 2005 at 15:03 UTC
    Do I really want information on what products my customers put in their temporary shopping carts, products that at the end, won't be bought?

    Yes. That information tells you what isn't selling and, potentially, why. For example, let's say you tracked this information and noticed that there was a pattern of how people used their shopping cart.

    1. Add item A
    2. Add item B
    3. Visit page 123
    4. Remove item B
    5. Add item C
    6. Check out

    I'd be a little curious as to why people always remove item B after visiting page 123, then add item C. It may be that you're not selling item B because there's a bad review on page 123. Or, it may be that page 123 says that item C is a better version of item B. Or, ... I'm sure you can think of other scenarios.

    The point is that it isn't sufficient to know what items your customers buy. It is also important to know how they shop. And, a shopping cart gives you unprecedented access into the browsing habits of your customers.

    Now, this idea has a few catches to it.

    • You need the space to store this information. Not just the shopping cart itself, but what pages the customer views, when, and for how long.
    • You need some algorithm(s) that will analyze this information for you.
    • You need to actually look at the analysis.

    Luckily, there's a pretty simple, if data-intensive, solution, and it may be one you have already partially implemented. Most web applications will track the following:

    • every request they receive
    • which user/SessionID made the request
    • when the request was received
    • when the response was sent
    • if any errors were generated

    This information is very important in terms of analyzing your application's performance. The error stuff is really useful for paging out to a support person in realtime when an error occurs. (I once called my director at 10am on a Sunday to ask him to try a page again after I fixed an error he ran into. He quickly stopped complaining about my "unnecessary development initiatives".)

    To that, add the session state as it was at the end of the request and you have all the information you need to analyze the browsing habits of your customers.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

      I had thought of this but you really proved the point. Thanks for a great reply!