Re^2: Code Design Issues

A session should be used to store session information. What is session information? It's anything that has to do with the current session. If your session is a shopping cart, it's whatever you want to do with the shopping cart, like productID, name, and price.

Now, the security of this session is as good as the security of your database, because it's stored in the database. None of it is exposed to the user beyond the exposure your database has to the user. Which, in most cases, is good enough.

I wanted to use sessions instead of the database to minimize unneccesary database calls, is this really an issue?

I don't know - have you seen an issue? In 99.999% of all situations, rearranging code to minimize X is a bad plan, because X isn't a problem. For example, let's say that by having the maximum number of database calls, your pages return, on average, in 3 seconds. Is 3 seconds a problem? I don't think so ...

Now, let's say that you can rearrange your code, making it harder to work with, and shave 50% off of your database usage. You end up taking twice as long to make a change, but your database time is down by 50%. Since database calls, in my experience, usually account for either 20% or 80% of the total time most applications spend on a request, you either saved 10% or 40%. This brings your 3s response time to 2.7s or 1.8s. Even in the best case, I don't think most users will even notice you did anything.

Now, database call optimization can be important, but only when you start receiving above 3-5 requests per second. Anything below that is easily handled by most modern databases, including MySQL, when running on most modern machines.

I don't want a growing shoppingcart table, Tanktalus had a good point considering if this data could be of any intrest?

Do you want to know what people are buying? Do you want to know when they're buying it? Do you want to know who bought what? Most retailers would kill for this information, but you're not sure. Riiiight.

For example, let's say you have a product ABC. ABC seems to be purchased almost exclusively between 10pm and 3am. So, maybe you want to start targeting users that login during those times and mentioning "You might want to look at product ABC." Or, you might want to do something like Amazon does - "People who bought ABC also bought these items".

This is the heart of your store, man! You lust for this information. Plus, you might be legally required to gather this information, depending on where you are and what you're selling. For example, if you sell some items that are age-restricted and some that aren't, you may have to prove that all the age-restricted items were purchased by users that had verified their age in some fashion. The only way you can do that is if you have a complete history of all purchases.

And, if you have that complete history, you can do neat things like provide copies of receipts for a dollar. :-)

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.

Comment on Re^2: Code Design Issues

Replies are listed 'Best First'.
Re^3: Code Design Issues by boboson (Monk) on Feb 07, 2005 at 14:40 UTC
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?	[reply]
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. Add item A Add item B Visit page 123 Remove item B Add item C 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.	[reply]
Re^5: Code Design Issues by boboson (Monk) on Feb 07, 2005 at 15:15 UTC
I had thought of this but you really proved the point. Thanks for a great reply!	[reply]