I am trying to find a pros/cons explanation of the best method, session array or database tables, for building a shopping cart. The latter allows for cart contents to be saved for a future visit by an unregistered user, but are there any major reasons not to use database tables to track shipping cart items? What sort of table structure would be most efficient? Is there a good place to look for these answers?
Cheers
N
Ive tried storing information in session and database.. Trust me on this store items for each session in a database, reason being i wanted to add a remove items and also have a delete individual items. In the end errors just kept on happening, so eventually decided to use the database. However still use a session so you can track the user.
With respect I disagree.
If you use databases to record everything that a user chucks into the basket then you'll end up with lots of redundant database tables wasting space on your server. It can also cause problems when the user revisits the store only to find that last weeks basket is still intact.
I have successfully used session control in shopping carts and have had no problems at all. Check out www.parkerandhobbes.co.uk for an example of my work.
Originally posted by Davidc316
With respect I disagree.
If you use databases to record everything that a user chucks into the basket then you'll end up with lots of redundant database tables wasting space on your server. It can also cause problems when the user revisits the store only to find that last weeks basket is still intact.
Then you store the session ID in the database (I presume you meant "records" and not "tables"): coming back later they'll have a different session ID and hence a fresh basket. Also/alternatively, store the time that the record was added and delete records more than e.g., 24 hours old.
personally, i want my cart persistant as long as i haven't payed for things........ ergo, i should delete items only as the user pays for them.........
Originally posted by Moonglobe
personally, i want my cart persistant as long as i haven't payed for things........ ergo, i should delete items only as the user pays for them.........
But do you want them to be persistent for twenty-four hours? How about a week or a month, then? A properly indexed table (on session_id) will run quite fast enough even if there are lots of dud entries (from people who were just farting around or who changed their mind and wandered off).
Another advantage of using a database is that using the (default) file-based sessioning system incurs the overhead of reading and writing all those files on every sessioned script access, while a database will have swapped the relevant indexes and chunks of table b-tree into core and have them cached there.
So the table below could function as an effective cart?
CREATE TABLE `cart_items` (
`item_id` int(11) NOT NULL auto_increment,
`product_id` int(11) NOT NULL,
`date_added` timestamp(14) NOT NULL,
`session_id` varchar(50) NOT NULL,
PRIMARY KEY (`item_id`),
KEY `sessions` (`session_id`)
) TYPE=MyISAM;
If I wanted the cart to be persisitent for one month for example, would I create a separate cookie containing the session id, to allow for the same cart items (provided they have not been automatically deleted after one month) to be reloaded when the user returns? Would it be preferable to create an independent cart_id? Is it all academic at this point? 
Originally posted by Davidc316
With respect I disagree.
If you use databases to record everything that a user chucks into the basket then you'll end up with lots of redundant database tables wasting space on your server. It can also cause problems when the user revisits the store only to find that last weeks basket is still intact.
I have successfully used session control in shopping carts and have had no problems at all. Check out www.parkerandhobbes.co.uk/shopfront.php for an example of my work.
I guess that depends on the type of shopping cart. The cart i had needed to have multiple entries, add, update, delete single entries and of course empty cart. Deleting Single entries caused many errors maybe the way i set it out, maybe you can show me your way for future reference.
Anyway about having records in the database. basically the way a good one is setup no matter if you want the cart to exist for ever or delete straight away is to keep all the items in a database until its paid for once that happens add the information somewhere if the user wishes to have a history of paid items.
Listen, maybe I'm just being old fashioned here, but if I went into my local Walmart and somebody handed me last week's shopping trolley (just incase I wanted to purchase all that stuff today) then I'd be pretty cheesed off.
It sounds to me like you're wasting your time on fancy features that are going to be totally useless to both you and your customers.
I kind of like that fact that on some sites I can drop something in my cart and then go away knowing that at a later date it will still be there when I'm ready to buy. It's like the wishlist feature at amazon. Browsing on big sites can be time consuming and if the site can remember me, all the better for both of us. The site gets to remind me what I was interested in last time, and get a second chance at making a sale. You can always delete the item if it doesn't interest you anymore.
That said, there should be a "best before" date on a shopping cart so I'm not looking at clothing for toddlers when my son is entering high school.
Why not use something like oscommerce?
im not sure on macosxguy's opinion but mine is that oscommerce is just way too big for what is required. yes its good but its far to big and complex for that matter.
My two cents on that: I prefer to improve my php/mysql skills by building something to my own spec (starting with a basic framework like mymarket over at sourceforge) than trying to modify a package as complex as oscommerce. Besides, the markup is unreadable with all the intertwined PHP, and isn't valid XHTML.
Personally, I agree with Weed's point of view and his handling of sessions in the database, but I also see the value in saving a cart - I know I've gotten interrupted or accidentally closed the browser and lost everything in my basket and it's been quite irritating to recreate my shopping experience.
I believe the best solution is to perhaps give the shopper the chance to save the basket for the future... then store a 'user id' as a cookie on their machine and in the database as well if they choose to take advantage of this option.
This would also allow your user to create a "wish list" of sorts as macos suggested, or create a "recurring" cart for frequently purchased items (not sure what type of items you're selling).
-Elizabeth
This maybe stupid but, why not just have people register then each member has his/her own cart like Amazon or any other place? Maybe I'm just missing something here.. 
And personally I would like it if stuff I put in the cart stays there till A) I purchase the item or 
I delete it from there myself! If I added stuff to my cart and came back later on and it was gone I would be seriously annoyed!
Making people register before they can shop is definitely out of the question. In my opinion users shouldn't ever have to register just to buy an item. It should be optional.
This is in no way meant to be a dig or anythnig like that, but I just wondered why it was out of the question for people to register?
I have no idea what it is you're selling, but if people were allowed to register, it would mean that you could store their names and addresses so your customers wouldn't have to type them in again.
Just a thought...
It's not out of the question for people to register, but for me I prefer not to force people to register before they can buy. Walmart doesn't require you to give all your personal details and choose a password and username just to make a purchase, but if you wanted personal service, like membership in a rewards program, that's when the extra step would be warranted. I'm just talking about your average items. In my case a jewellery store. Creating a username and password will be the final step before payment processing, and even then it will be optional should the customer choose for their personal details to be stored in my database, and for them to have to remember yet another username/pass.
I guess I'm trying to minimize the number of obstactles between me and my customers' money Abandoned shopping carts due to unneccessary intrusiveness is just such an obstacle in my view.
Macos, I believe you are absolutely correct (sorry Piers ). You should not force people to register, but giving them the option is certainly okay (I've been doing ecommerce for a long time now- forcing people to do something they're not comfortable with is a BIG no-no).
And if you do give them the option to register, of course you want to make sure they know that it's free to register, it's only to their benefit for order tracking, etc. , and that their information is absolutely secure and not going anywhere (as in other companies).
-Elizabeth
No you shouldnt force them to register, but giving them the option and telling exactly what its there for is a good idea. Anyway im still on the newbie side of Ecommerce havent done a great deal of it, but forcing a user to have to do something is like commiting suicide for a business.