Shopping Cart

suarve

suarve

suarve

Soldato
Joined
8 Oct 2005
Posts
4,184
Location
Midlands, UK
Just a very quick one now. I'm using ASP to make a shopping cart, am using a SQL server and have been going over a several examples. I can't make my mind up which way to code it (E.g. which way is best):


  1. Using tables (E.g. inserting the session id and product ID and quantity into a temp table, probs the slowest and most inefficient but simplist)
  2. Using ASP's dictionary object with an Array (Keys, value pairs etc)
  3. Or using XML and writing the minimal details to a XML file.

Thanks
 
Out of those three, number one is actually the fastest - databases are designed to be good at storing data.

Don't use a temp table though, just use a normal table called "cart" (or whatever follows your naming convention). Bonus is that you can do a simple join and get product details showing up in the checkout/view cart pages.
 
Seriously #1 is fastest? So say i added an item to the cart id be inserting my session id, product id, quantity and maybe price into the table. If I wanted to remove an item I'd run a delete query and to amend quantites an update query. Wish I could find something that compares methods of making a cart as the database would have been my last choice tbh.
 
Databases are by far the quickest of those methods and the easiest to code for.

Also, I'd avoid using the sessionID as these are not guaranteed to be unique - especially if the server is stopped/restarted at any point.

For a basic shop I'd just have a 'Basket' table, and create a new basket when a user adds a product. You can then save the BasketID in a cookie so they can be retrieved later if needed.
 
humm. This has me thinking now. I was going to use an array to store recently viewed items for a user. Would you recommend using a database for this too?
 
Yup, an array of productIDs stored in the session object would be the easiest was to do a MRU list - assuming you don't want it to remain accross various sessions, in which case you'd either need to store it in a database or cookie.
 
When I had to put together an ecommerce site in a couple of weeks I used the database for near-everything. MRU I stored in a session array then serialised to db upon logout (for registered users) which I thought was quite neat :)
 
Beansprout said:
When I had to put together an ecommerce site in a couple of weeks I used the database for near-everything. MRU I stored in a session array then serialised to db upon logout (for registered users) which I thought was quite neat :)
Click to expand...

I always get an "icky" feeling about serialising data and putting it in the database, especially if it's for long lasting data - what happens if you change platform, or even just upgrade to a new version of the current platform...all kinds of fun there.

If you must do it, I'd suggest converting it to a platform independent format (either xml, or maybe even json) for future proofing.
 
Just another quick question, if I'm inserting data into an orders table, how can I handle orders where people have added items but not bothered to check out (E.g. just left their basket). If I leave it won't the orders table get bogged down with garbage data?
 
Confused said:
Have a Basket table and an Orders table.

Save the temporary data into basket, and only put into orders once the checkout process is complete.
Click to expand...

But wjhat can I do about this temporary table, won't it just fill up with data indefinately?

Only solution I can think of is to have some option in the admin panel that the user would run from time to time that deletes old entries in this database.
 
The baskets table wouldn't be a temporary table, but it would eventually end up full of baskets which were never ordered.

You could - if they weren't required for tracking or metrics purposes - write a query to delete any basket which didn't have an id in the orders table.

TBH I wouldn't worry about it unless space is a concern on your database.
 
You must log in or register to reply here.
Back
Top Bottom