views:

234

answers:

2

Writting an asp.net shopping cart. I am leveraging the session for state but I also want to store basic info in a cookie. This info would be the items / qty. I am aware of the cookie size limitations but here the question.

Are there any sources of information on performance cost in terms of writting to a cookie as opposed to sql. In my current use case, I would at most be writting to the cookie on each page post (of course only the pages that had to deal with the shopping cart)

Just trying to determine the negative sides to using a cookie.

A: 

In my experience writing a cookie is a lot less cost than making a database call but how much data do you want to store and does it break the functionality if the client blocks cookies?

If you wish to persist session using a cookie, why not make an identifier cookie once when they arrive first time for the user and store this id on the session data. then when a session ends without saving the basket (i.e. on the session end event) flush the session data to the DB with the cookie identifier. Then when the user returns to the site later offer to restore their last basket from the DB by getting the cookie identifier.

Richard
+3  A: 

There are too many factors at play to be able to answer that question.

How fast is your database? How fast is the network? How fast is the end users network connection?

In general: cookies are reasonably fast enough. But so is a well constructed database call.

I look at other factors when making this call. Cookies can go away, they timeout, and you generally have no real control over them. Is that a problem? If yes, then do sql. If not, then do a cookie. Is security of the data an issue? If yes then do sql.

BTW: Most shopping carts that I've done use sql for most of that data.

Chris Brandsma
I agree with all the factors, I come from a sql backend shopping cart and there were some things I did not like about the architecture.The data in the cookie is not valueable and destruction is ok.
Dustin