|
|||||||
New to SitePoint Forums? Register here for free!
|
![]() |
|
|
Thread Tools | Display Modes |
|
|
#1 |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Jul 2002
Location: Dallas, TX
Posts: 349
|
Ok, I am trying to write a custom shopping cart system for a small site that
sells candles. What I can't decide is whether to use Sessions for the cart data, or a database. Does anyone have any recommendations? What are the advantages and disadvantages of both? I started to do the site with all of the cart data in Sessions, but as I started to put the data into the Session variable, I noticed that I was needing nesting Arrays (and more nesting arrays). Here is a sample of the Session data that I had when three items were added. As you can see, the [5] and [3] arrays are the part numbers. The [5] array has two candles inside of it. They are the same part number with the same Name and Price, but they are different scents and each scent has it's own quantity. The candles in the database are one row per part, but each part can have an attribute (the scent). So my arrays started having arrays which also had arrays. Here is the output of the Session array... Code:
Array ( [Cart] => Array ( [5] => Array ( [Apple Cinnamon] => Array ( [Name] => Victorian Jar (10oz) [Price] => 7 [Quantity] => 1 ) [Bay Breeze] => Array ( [Name] => Victorian Jar (10oz) [Price] => 7 [Quantity] => 2 ) ) [3] => Array ( [Grape] => Array ( [Name] => Glass Flower Pot (4oz) [Price] => 3 [Quantity] => 1 ) ) ) ) Ok, so if Sessions are ok for storing shopping cart data, am I storing my data in a effecient way? Each part that is added is an array under the [Cart] array (Which is under the $_SESSION array). Each part has an array for each scent that is added, and each scent has an array that holds the Name of the Part Number as well as the Price and Quantity. Should I put the Part Name and the Price under the Item Number instead of putting them under the Scent? The Part Name and Price will be constant for each Part Number, so putting it under each Scent would be duplicating data, but the way that I have it now, all I have under each Part Number is a list of arrays, not Two Strings with an unknown amount of arrays. Is that confusing? Ok, so my other alternative is to go with storing the shopping cart data in the database. If I do that, I am not sure what I should store. Do I have just one big table that looks like this Code:
Session ID Part ID Part Name Scent Quantity XXX 1 Candle 1 Blueberry 1 YYY 3 Candle 3 Strawberry 3 XXX 6 Candle 6 Orange 6 in the database, would I just move it from the cart table to the "orders" table once the order has been processed? If so, what would I do with data that was put in the cart by someone, but the order was not processed? Wouldn't the table just fill up with data? How would I go about trash collection? Or would I just leave it there? Please, if anyone has any suggestions or answers to the questions above, please let me know. I am an intermediate newbie trying to do something I have never done before. I would prefer to start out by doing it the right way, rather than doing it the "not-so-right" way and find out later, only to have to do it over. Thanks in advance (and more afterwards) |
|
|
|
|
|
#2 |
|
SitePoint Wizard
![]() ![]() ![]() ![]() ![]() ![]() Join Date: Aug 2004
Location: California
Posts: 1,672
|
Use sessions if all you every want is a simple cart.
Use a database if you want to do things like save carts, have wish lists, do analysis of user's shopping patterns, etc. |
|
|
|
|
|
#3 |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Jul 2002
Location: Dallas, TX
Posts: 349
|
Ok, I will probably use the database to store cart data then. Does anyone have any suggestions. Like would I use only one table for the cart data, and would I use the session ID as the primary unique key? Does anyone have any general tips to throw my direction. Maybe a list of everyone's suggestions about what they think is the best method of storing cart data?
|
|
|
|
|
|
#4 |
|
Non-Member
![]() Join Date: Sep 2004
Location: United Kingdom (Come)
Posts: 80
|
Yo
You would use sessions regardless as you need persistence from page to page as the visitor navigates your web site. I would also store their basket to the database short term in the event the session is lost, thus you pick up the basket again based on a cookie. Once the visitor does make an purchase, you move their basket to the tables you have for storing their name, address, zip code, etc and remove the basket you stored in the table I stated above ![]() |
|
|
|
|
|
#5 | |||
|
SitePoint Addict
![]() ![]() ![]() Join Date: Jul 2002
Location: Dallas, TX
Posts: 349
|
Quote:
![]() Quote:
Quote:
Thanks for the quick reply too |
|||
|
|
|
|
|
#6 | |
|
Non-Member
![]() Join Date: Sep 2004
Location: United Kingdom (Come)
Posts: 80
|
Yo
Quote:
If someone has their cookies disabled, then nothing much you can do about it, just alert the user that they need to enable cookies is one option ? Cookies are not that difficult to work with or understand, look at the on line manual to begin with, then look at Kevin Yank's articles. One has something to do with using cookies which will help you out a lot ![]() |
|
|
|
|
|
|
#7 |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Jan 2004
Location: New York
Posts: 256
|
Look up HEAP table types. Session variables are stored on HDD, but data on HEAP tables are stored in memory.
|
|
|
|
|
|
#8 |
|
SitePoint Evangelist
![]() ![]() ![]() ![]() Join Date: Jun 2004
Location: Australia
Posts: 498
|
I'd go for sessions and create a cart class so you simply instantiate the cart class and have your add_item() display_item() and calculate_total() functions within that.
try www.phpclasses.org for a few decent carts. I modified one of those under GPL and its great for all basic carts. Database storage has its benefits including storing temp carts for a long time so users have their contents when they come back - but that is also dependent upon cookies. One problem I had recently with a sessions cart was shared SSL with trans_session_id turned off - the cookie domain changed whjen it went shared SSL and the cart was lost. A database cart solves that issue at least. |
|
|
|
|
|
#9 |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Sep 2004
Location: secunderabad
Posts: 273
|
Database could be better for future references but you can head with sessions for basic displays that can store the basic values like items and the user info, others could be stored and fetched thru DB which eases the job of data being lost if there are other secured reasons.
I have always worked on data storage for carts. Regards |
|
|
|
|
|
#10 |
|
SitePoint Member
Join Date: Sep 2004
Location: UK
Posts: 1
|
I will shortly be tackling this same issue. Our site has close to 20,000 lines for sale and we will likely have 2 options for customers.
1. create an account and log in - this would enable wish lists etc. 2. no login - basket held in database, but indexed by session. I have not fully thought this out yet, but I see no need to have a separate table for basket and order items. I would have a table 'tblBasketHeader' linked to 'tblBasketItems' by a key field. 'tblBasketHeader' would have fields for 'sessionID', 'customerID', 'status' etc. and a field 'orderID' which would link to a table 'tblOrderHeader' once an order was placed. This would contain order specific info. such as delivery address etc. A script could be run periodically to delete entries from tblBasketItems and tblBasketHeader which had no customerID OR orderID AND which fell within a date range (say, older than 1 month). |
|
|
|
|
|
#11 |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Sep 2004
Location: secunderabad
Posts: 273
|
well we dont have to have a seperate table for each item or say each entity, we can have a common table on orderId which would have entries of the order items and customer details, well it depends upon how much load your server can take as well with other constraints playing role!!!
|
|
|
|
|
|
#12 |
|
SitePoint Member
Join Date: Sep 2004
Location: Port Lincoln, South Australia
Posts: 6
|
I have just implemented one for a customer and it was done by filling a tmp_order db with each item. (bit like a transaction db)
On completion of the order, a main order record was created with an order number (with custid, date, total order value, freight etc.). On order confirmation the tmp_orders were dumped to a more permanent db (with the order_id from the primary order record as a secondary key) This allowed the order (and products) to be tracked, processed as well as statistics gathered for the client. We did a 30+ user test on 70 odd products from 5 categories and it performed flawlessly. By doing it this way you can simply call the summarised order details from your https connection direct from the db and not worry about carrying session arrays around... I used the session_id to differentiate simultaneous customers - this allowed me to key into the db from either side of SSL. Apart from that, there should be no need to carry the whole order to the payment area, just the custID and order total... Hope this helps a little... It worked for me - beautifuly.. |
|
|
|
|
|
#13 |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Sep 2004
Location: secunderabad
Posts: 273
|
that was my point, I am sure Steve's way of doing is same as I did for my carts and it surely increases the performance and eases the job in future.
|
|
|
|
|
|
#14 |
|
SitePoint Member
Join Date: Sep 2004
Location: Port Lincoln, South Australia
Posts: 6
|
Sorry Sinapra - soundz like I woz stealing your thunder
![]() |
|
|
|
|
|
#15 |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Sep 2004
Location: secunderabad
Posts: 273
|
not at all, your explaination was clearer than me
, I hope it can be effective to the users!!!! |
|
|
|
|
|
#16 |
|
Non-Member
![]() Join Date: Sep 2004
Location: United Kingdom (Come)
Posts: 80
|
Yo
Found some old script I had from a while back, hope it's some use to someone ![]() PHP Code:
PHP Code:
PHP Code:
PHP Code:
PHP Code:
PHP Code:
PHP Code:
![]() |
|
|
|
|
|
#17 |
|
Non-Member
![]() ![]() ![]() ![]() ![]() Join Date: Sep 2004
Location: Florida
Posts: 644
|
In your cart database it may be good to also store the actual price paid. That way if the product price changes in the future it won't effect the integrity of your historical data.
|
|
|
|
|
|
#18 | |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Jul 2002
Location: Dallas, TX
Posts: 349
|
Quote:
should there be any reference to the parts table? Like should I put the PartID of the product that was ordered which would link it to the product details (specifically the name and price), or should I put the product name and price in the orders table as well. Because what happens if in the future I rename or even remove a product from the database, will the orders table be broken or linked to missing data? And in the future, instead of removing products from the products table, should I just have a field that decides whether or not to display them on the web? Is removing products that have been ordered a bad idea? |
|
|
|
|
|
|
#19 |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Apr 2004
Location: Regina, SK
Posts: 344
|
I would be very careful using the sessionid as your unique/primary key/whatever. Remember, the sessionid is tied to that session. If the user's browser crashes/closes/whatever, all the information stored is essentially lost. In similar situations I've instead used something like md5(time() . $client_ip) or something like that. Then store this key in the session. If the user's browser closes for whatever reason, when they relogin you can retrieve this key and things are exactly where they left.
|
|
|
|
|
|
#20 | |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Jul 2002
Location: Dallas, TX
Posts: 349
|
Quote:
how is storing the sessionid in the database (and a cookie to retrieve it later) any different than storing md5(time() . $client_ip) in the database (and a cookie to retrieve it later)? Wouldn't it be the same thing if you just stored the sessionid in a session variable and used it in the cookie and the database? And if the browser closes/crashes or whatever, you would recall the variable from the cookie, and it wouldn't really remember what the value was, just that it matches what was saved in the database, right? I am still learning, so I am asking if it's the same thing, I'm not telling, k? Thanks for the idea to think about too. |
|
|
|
|
|
|
#21 | |
|
Non-Member
![]() ![]() ![]() ![]() ![]() Join Date: Sep 2004
Location: Florida
Posts: 644
|
Quote:
|
|
|
|
|
|
|
#22 | |
|
Non-Member
![]() ![]() ![]() ![]() ![]() Join Date: Sep 2004
Location: Florida
Posts: 644
|
Quote:
|
|
|
|
|
|
|
#23 | |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Jul 2002
Location: Dallas, TX
Posts: 349
|
Quote:
do they check for a session variable, and if there isn't one, then they load it from the cookie and store it in a session variable? Is there any advantage for one or the other, either pulling the cookie on every page load, or using the session variable on every page load and if there isn't one, then load it from the cookie? |
|
|
|
|
|
|
#24 |
|
Non-Member
![]() ![]() ![]() ![]() ![]() Join Date: Sep 2004
Location: Florida
Posts: 644
|
The sessionID itself is stored as a cookie (or url query if not available). So a site that keeps you logged in is usually reading a cookie on every page load whether or not they employ built-in php sessions. I guess the question would be is it better perfomance wise to read the user-info from the database on every page load or to store it in the session at log in and read it from there on every page load. Since the session data is written to a file on disk, I don't know if there would be any advantage to this as opposed to reading the data from mysql.
|
|
|
|
|
|
#25 | |
|
SitePoint Addict
![]() ![]() ![]() Join Date: Jul 2002
Location: Dallas, TX
Posts: 349
|
Quote:
pageload (plus any other database stuff you do on that page), right? Accessing a session variable is quicker than making a database connection, making an sql query and closing the database connection from what I've read. But I COULD be wrong...I'm used to it. |
|
|
|
|
![]() |
| Bookmarks |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
| Display Modes | |
|
|
|
All times are GMT -7. The time now is 01:45.










Linear Mode
