Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

For my final project in school we have to develop an online shop. This shop should have a cart where items can be placed whether or not you are logged in. If you log out the cart shouldn't empty and should still be shown.

So my question is would it make sense to store the cart as xml in the database(ms sql server)? There is potentially a (relatively)fair amount of data that should be kept, is it possible that this could deliver any performance benefits or am I way off base?

share|improve this question
add comment

3 Answers

up vote 3 down vote accepted

This shop should have a cart where items can be placed whether or not you are logged in. If you log out the cart shouldn't empty and should still be shown.

Those requirements seem to ask for client side storage, that is either cookies or localStorage. But of course you could set a simple cookie, separate from the session cookie, that reference a shopping cart stored in the database.

I don't see much need for XML in this job, while at times there may be a performance benefit from collecting a lot of data in a single string (that could be in XML form) and storing that in the database, rather than storing the same data as a lot of entries, I do not think that applies in this case since you update a lot, you don't read a lot, and when you do read you need the data split for further handling immediately.

share|improve this answer
    
Thanks! That makes sense. –  The_Cthulhu_Kid Jan 11 '13 at 20:05
add comment

I have worked on a system which implemented a shopping cart in precisely this fashion: "in-progress" shopping carts were serialized to XML and stored into a single field in a single table in the database.

The reason to do this isn't so much performance as ease of development. I suspect that once upon a time, shopping carts were only stored in session state, so if you browsed away from the site and returned an hour later, they would be gone. I suspect that when a request came in to make them persist against a user, the quickest way to do it was just to decorate the various classes involved with XML serialization attributes, serialize, store.

The pitfall to watch for is that this will make it difficult to do much with the data other than storing and retrieving individual users' carts. For example, if a particular product is removed from the catalogue, you might want to remove it from any shopping carts. If you had your temporary carts stored as a bunch of tables you'd simply find them with something like SELECT * FROM ShoppingCartItems WHERE ProductID=@productIdToDelete. If it's all in XML blobs, that won't be straightforward, and you may find a better approach to just re-validate all carts when they are retrieved from the DB and deserialized.

share|improve this answer
    
I think for the purposes of the project it would be too much as the cart will probably change often. But thank you. –  The_Cthulhu_Kid Jan 11 '13 at 20:42
add comment

Whether to use a server-side database or a cookie depends on whether you want a user to have the same items in their shopping cart when logged on from another (device/browser). Unless the user goes insane and orders thousands of items, the amount of data isn't likely to be a major factor.

Whether you store the data in XML, JSON, or some other format depends on your preferences and your environment (e.g., are the tools you're using better at dealing with XML than with JSON?).

The data you store itself should be pretty minimal--you don't want to replicate pricing, product details, etc., in your shopping cart data.

share|improve this answer
    
The project will never actually go live and I understand that there isn't much data involved. I am just in the planning stage at the moment and have to think ahead to my presentation (I have to talk a lot if I want a distinction). Do you think it might be worth implementing or should I concentrate on an other area? –  The_Cthulhu_Kid Jan 11 '13 at 17:46
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.