我应该将购物车数据存储在会话中还是数据库中？（我认为在用户注销后在 amazon.com 购物车中并在一个月后再次登录他在购物车中选择的订单保存）谢谢，Yosef
问问题
35636 次
5 回答
62
当然，购物车数据是一个关键数据。在哪里保存这些数据取决于您的电子商务系统工作的那个用户。
对于未签名（尚未）的用户 - 您必须将此数据保存在网络存储中，html5 为您提供了此功能。使用前端存储很简单，它配备了任何浏览器（Cookie、会话存储、本地存储）。在结帐过程系统必须要求用户注册。注册后，您必须将此数据与数据库同步。否则，您不必将这些无法追踪的数据保存在数据库中。
使用已签名的用户 - 当然是在数据库中。通过这种方式，您可以正确跟踪用户的篮子。如果用户从任何地方登录，您可以向她显示他的帐户和“待付款项”。并将这些数据保存在浏览器存储中取决于您的喜好。
此信息也可能有帮助客户端与服务器端购物卡存储
于 2016-10-19T11:47:57.413 回答
17
I am winging it here. Make a flexible / progressively enhanced shopping cart.
Not Logged In
Plan A) If Web Storage, use it (session storage / local storage) knowing that ALL customers' cart data can be aggregated into a tracking cart database table (with time stamps and session ids) using AJAX, too. Synchronization and pruning is key (client, tracking table). No server-side session storage of individual cart data is required.
If the browser closes, the cart can be re-established. Closing the browser gracefully should result in an AJAX call that prunes the tracking table.
The tracking cart is not authoritative (used to impact / reserve inventory) because it does not represent an identified customer on the verge of paying. Only if the customer hits check-out will the items in the tracking cart matter in terms of inventory (there is still more to do, though).
Plan B) Else, fall back to logic for [server-side] session cookies only. Use AJAX to read/write data in the centralized cart tracking table. The client never stores individual cart data, nor is it stored in session data (database driven, or not). As long as the client is not logged in, their cart data is in the centralized tracking cart only.
If the browser closes, the client-side cart is lost for good. If the browser closes gracefully, items will also be deleted from the tracking table utilizing an AJAX call. Otherwise, old cart data in the database is pruned by activity time stamps.
Alternative Plan B) Implement a persistent client-side solution using standard, encrypted cookies. This way, whether the browser closes gracefully or not, the client-side cart can be re-established and the tracking cart table updated. This would support older user agents and save them some frustration at the cost of doing more programming and testing.
Note: You must anticipate and handle the reality that session ids will change throughout the lifetime of the session. If you want to avoid session fixation, you cannot use the same session id over and over again for each HTTP request. Hence, you must UPDATE the session id in the master tracking table upon each request.* This could be a lot of updates if many users are not logged in and they have many products in their carts.
Logged In
When a customer logs in, you copy their tracking cart contents to their own shopping cart table (regular table, not in session). The shell game will now be played between the client, cart table data, and the master tracking cart. The user's cart contents are now persistent regardless of the user-agent. The user's shopping cart table is not yet authoritative, either.
Only when the users hits check out will the user's cart contents impact inventory availability. Only after purchase will actual inventory decrease.
That last line brings up an important point. There is a difference between what is available and what is in stock. Due to a website's concurrency of use, any number of people may put the same item in their cart without it becoming unavailable.
If there are 10 Linux books in stock, 20 people could put 1 copy into their cart. The first ten are not a problem, but should the second ten be shown a message SOLD OUT? No. What if 15 people walk away, say never-mind, but never empty their cart? All should see IN STOCK, but only those who hit check-out should impact availability. Those who pay should affect inventory.
Thus, in setting up your product tables, be sure to have two fields for tracking products: availability and quantity. They are related, but in the e-commerce sense they are not the same.
Final Note: In a load balanced web server scenario (Amazon Web Service users will probably agree), it is more likely that sessions will be handled by a database because it makes it easier to centralize the data. While it is possible to have a networked, centralized, and file based / NFS session store on a NAS type solution, that may not be advisable or optimal (latency, file locking issues, not to mention security configuration).
于 2018-02-19T16:59:51.973 回答
8
两者怎么样？当您阅读购物车数据时，请先检查您的会话。如果它在那里，您可以保存一次到数据库的行程（如果您的会话没有数据库支持）。当您写入时，写入会话并持久化到数据库。这样，您可以快速阅读，并且用户在关闭浏览器时不会丢失购物车。
于 2010-05-13T15:01:04.687 回答
3
如果您的购物车软件可以充分利用废弃的购物车（发送提醒，也许他们应该回来完成销售等）并将它们从数据库中清除并进行良好的数据库清理，然后将它们保存在数据库中。
如果它只允许返回用户继续使用当前购物车项目，则将它们保存在 cookie 中。
如果您在回访时想要一辆新鲜的购物车，那么可能会在会议期间离开。
于 2010-05-13T15:00:18.817 回答
1
我经常首先将购物车数据更新到数据库中，并为只读请求保留一个缓存版本，例如在每个页面上显示一个迷你购物车。购物车数据应经过优化读取。而且由于购物车数据通常很小，所以我想为匿名用户保留几个月，也将其存储在 cookie 中。
于 2010-08-22T14:15:28.213 回答