Good day. I took on an atypical genre for myself - an online store. Posted Everything seems to be working. You can even make an order. It turned out a bit cumbersome, but according to test data, it still works faster than Joomla. And when I had all the work almost completed. I understand that I used sessions very inefficiently. With their help, I only passed a unique user id and a few more parameters. To store data from the shopping cart, I created a separate table and scored the data there. The disadvantage of this approach is that on almost every page, there is an additional query to the database.

Tell us how you implement a basket of goods in the online store and what do you use? Sessions, DB, or Cookies?

Closed due to the fact that it is necessary to reformulate the question so that it was possible to give an objectively correct answer by the participants of LEQADA , torokhkun , user185447 , Axifive , Vladimir Glinskikh 10 Dec '15 at 16:18 .

The question gives rise to endless debates and discussions based not on knowledge, but on opinions. To get an answer, rephrase your question so that it can be given an unambiguously correct answer, or delete the question altogether. If the question can be reformulated according to the rules set out in the certificate , edit it .

    4 answers 4

    Consider for each item.

    Storage in the base, advantages:

    • Do not scare the user crashes browser.
    • the administrator can always view the user's order, correct it.
    • user can sit with multiple browsers at the same time.

    minuses:

    • extra database request (but memcache can be used)
    • the base must be cleaned from time to time or write the correct algorithm to complete the purchase.

    Storage in session, pluses:

    • fast enough.
    • easy to clean.

    minuses:

    • more difficult to do balancing on multiple servers
    • harder to see what the user ordered there

    cookies, pros:

    • minimum storage space

    minuses:

    • It is impossible to know the current status of the order (of course you can, but if the user is logged in and makes a request).
    • difficult to modify user request.
    • do not store sensitive / sensitive information.

    My suggestion is that you store everything in the database, and the user has the amount of goods purchased / the resulting price in the cookie (to display the status of the cart on the page without unnecessary requests). When making a purchase - be sure to get it from the base. In this case, there will almost never be any extra requests. If a load balancer appears, then any memcache (or something like that - redis, mongo) is needed, which will give the current purchase status, with cookies it will be more difficult.

    Also, with each purchase, store the date / time - this will help to clean them if necessary.

    • Another plus from storage in the database is that you can analyze abandoned baskets and periodically prompt the user to complete the order - Bethrezen

    I would advise using LocalStorage (JS) + DB. So you can always store data about orders on the client side, transferring them to the service not every time (as is the case with Cookies), but only with the direct payment (registration).
    Pros:
    1. There is no cost for extra traffic and the load on the server database in the form of extra requests.
    Minuses:
    1. The server does not know anything about the user's basket, until he clicks "Pay."
    2. There is no synchronization with other devices (Suppose the user has a tablet and PC).

    But the cons are quite solvable:
    1. Know the server about the basket and do not need. The seller is included in the sale from the moment the button is pressed: Place an order. Then there is a request to the database and there are checks on the availability of goods, etc.
    2. You can perform a query to the server when adding a product (so there is created some "cast" or a cache of the basket). And on the client it is unloaded only if the previous request was made not from the current device.

    Total we have:
    1. Only one outgoing request to add to the database for each product.
    2. The number of cart samples from the database ~ the number of user devices (and not for each request to the site).

      I write small online stores, I came to the conclusion that the easiest way to store a basket is in the database. You can always make an AJAX request, recalculate on the server side. Yes, there are drawbacks, but what you have to sacrifice.

        It is best to store a user's order in sessions. So quickly and unnecessary queries to the database there. As soon as the user decides to pay, save his order to the database