shopping cart for non registered users

Question

I am in the process of making a website that involves a shopping cart. There are two major requirements:

1. The user experience guys want login/authentication to be the very last step in the entire work flow. The user gets to do all the shopping and is asked to login only at the time of checking out.

2. The shopping cart shouldn't expire(not even on browser close) unless the user (registered or not) does check-out.

In the above context, I have the following question with respect to maintaining the cart's state:

Should I go with file based or database sessions? Please keep in mind this would be for unregistered users. My apprehension is that I'll end up having lots of records in the database.

Another option seems to be to put the cart contents in an encrypted cookie, but then there's a size limitation on the cookie file.

What would you do in this case ? I would really appreciate your answers.

Answer 1

I would go with database managed sessions over file managed sessions. Make sure you have a session timestamp so that you can eventually kill old sessions (if it's been 12 months, the shopper is possibly not coming back for the items originally in the cart).

Doing this with a database instead of files will make it easier to eventually expire the very-old information.

Note that the database session will only ever be valid as long as the cookie it's tied to on the user's computer. If the user comes back to the store from a different browser, they will not find their session. If two people are sharing the same computer, they will find each other's session. Hopefully no potentially embarrassing items will be in the cart...

Answer 2

Store in cookies the AnonymousSessionID, with which you associate a shopping cart in the database.

Then you'll have a scheduler task to erase anonymous sessions after some time (say, a day). This will keep your database clean of abandoned sessions.

If a user registers, you reassociate their shopping cart with their account permanently. If the users makes an order, you empty their shopping cart.

Answer 3

With those specs I would go with a database based session state. But you should do some heavy reading on how session state is handled in your web server of choice. Since you want to be able to revive the state to the correct person.

Answer 4

1. Tracking a user. Use a GUID encoded into a cookie with an nYear expiry.

2. Storing a Shopping Bag. You don't want to store the bag in the cookie, mainly due its possible size. This leaves the option of persiting it to a medium and retrieving it from the medium. Using anything except a database for this would be like going back in time, databases excel at storing and retrieving data.

3. Managing you Shopping Bag. Now, the question of your schema, firstly, if your going to be running queries against the shopping bags in the database (i.e. how many shopping bags contain item x) you probably want a traditional relational schema. However this has overheads in terms of inserting. updating, selecting (and joining) and deleting bag data (at some point you'll have bags that will never be used again but are taking up precious disk space). With a busy site, this is a fair few Traranactions Per Second, but any database should be able to cope. If you don't need to query the shopping bags in the database, then you can store it as XML. Just serialize the bag and dump it into a table, with the PK as the GUID as stored in the users cookie. This would be a lot faster than a traditional schema, plus you could always tear apart the XML in the future if a requirment did come up for a relational schema.

This is what we do (Xml Bag), and we have a million+ customer base.

Answer 5

If you're using ASP.NET here's what I'm (about) to do:

• use a Profile to capture the users email as soon as possible (to email them if they dont complete the order). you can enable anonymous profile properties that are persisted to the aspnet database even if the user hasnt actually truly registered.
• stick an XML bag representing an order into session. This is persisted in the database with a regular identity ID.
• store the ID of the cart in the ASP.NET Profile. that way when the session expires you can just reload it from the ID in the profile. this has the benefit that the user never sees the cart ID in a cookie and you can easily link records between the membership/profile database and the store you're using for your orders

(dont try to store the XML order in the Profile. i think thats asking for performance issues. but in theory you could i suppose)

Answer 6

I think you have some expectations to manage, or maybe you weren't clear on requirements.

1. The user experience guys want login/authentication to be the very last step in the entire work flow. The user gets to do all the shopping and is asked to login only at the time of checking out.
2. The shopping cart shouldn't expire(not even on browser close) unless the user (registered or not) does check-out.

Specifically, an anonymous, not logged-in user's cart being saved? That's madness. Ensure that's not an expectation and clarify it in your design documents.