我应该在会话或数据库中存储购物车数据？ （我想在用户注销后的amazon.com购物车中，并在一个月后再次登录他在购物车中选择保存的订单） 谢谢， 约瑟夫
答案 0 :(得分：18)
购物车数据当然是关键数据。保存此数据的位置取决于您的电子商务系统所使用的用户。
使用未签名（尚未）用户 - 您必须将此数据保存在网络存储上，html5为您提供了使用前端存储的功能。装备任何浏览器（Cookie，会话存储，本地存储） 。在结账过程中，系统必须要求用户注册。注册后，您必须将此数据与数据库同步。否则，您无需在数据库中保存此无法追踪的数据。
使用签名用户 - 当然是在数据库中。通过这种方式，您可以正确跟踪用户的篮子。如果用户将从您可以向其显示其帐户的任何位置登录，并且＆＃34;待付款项目＃34;。将这些数据保存在浏览器存储中取决于您的口味。
此信息也可能有用[{3}}
答案 1 :(得分：7)
两者怎么样？阅读购物车数据时，请先检查您的会话。如果它存在，则保存到数据库的行程（如果您的会话没有数据库支持）。写入时，写入会话并持久保存到数据库。这样，您可以获得快速读取，并且用户在关闭浏览器时不会丢失购物车。
答案 2 :(得分：2)
如果您的购物车软件可以充分利用废弃的购物车（发送提醒，可能他们应该回来并完成销售等）并从数据库中清除它们并进行良好的数据库清理，然后将它们保存在数据库中。
如果它只允许返回用户继续使用当前购物车商品，那么请将其保存在Cookie中。
如果您想在回访时购买新车，那么可以选择离开。
答案 3 :(得分：1)
我经常首先将购物车数据更新到数据库中，并为只读请求保留缓存版本，例如在每个页面上显示迷你购物车。购物车数据应该被优化读取。而且由于购物车数据通常很小，所以我想将它保留给匿名用户数月，也将它存储在cookie中。
答案 4 :(得分：1)
我在这里徘徊。制作灵活/逐步增强的购物车。
计划A）如果是Web存储，请使用它（会话存储/本地存储），知道所有客户的购物车数据可以聚合到跟踪购物车数据库表中（带有时间戳和会话ID）也使用AJAX。同步和修剪是关键（客户端，跟踪表）。不需要单个购物车数据的服务器端会话存储。
如果浏览器关闭，则可以重新建立购物车。正常关闭浏览器应该会导致修剪跟踪表的AJAX调用。
跟踪购物车不是权威（用于影响/预留广告资源），因为它并不代表处于付款边缘的已识别客户。只有当客户点击结账时，跟踪购物车中的商品才会有库存方面的问题（不过还有更多工作要做）。
计划B）否则，只回到会话cookie的逻辑。使用AJAX在集中购物车跟踪表中读取/写入数据。客户端从不存储单个购物车数据，也不存储在会话数据中（数据库驱动或不存在）。只要客户端未登录，他们的购物车数据就只能在集中跟踪购物车中。
如果浏览器关闭，客户端购物车就会丢失。如果浏览器正常关闭，则还将使用AJAX调用从跟踪表中删除项目。否则，数据库中的旧购物车数据将被活动时间戳修剪。
备选计划B）使用标准的加密Cookie实施持久客户端解决方案。这样，无论浏览器是否正常关闭，都可以重新建立客户端购物车并更新跟踪购物车表。这将支持较旧的用户代理，并以牺牲更多编程和测试为代价来节省一些挫败感。
注意：您必须预见并处理会话ID在会话生命周期内发生变化的现实。如果要避免会话固定，则不能对每个HTTP请求反复使用相同的会话ID。因此，您必须在每次请求时更新主跟踪表中的会话ID。*如果许多用户未登录且他们的购物车中有许多产品，则可能会进行大量更新。
当客户登录时，您将其跟踪购物车内容复制到他们自己的购物车表（常规表，而不是会话中）。现在将在客户端，购物车表数据和主跟踪购物车之间播放shell游戏。无论用户代理如何，用户的购物车内容现在都是持久的。 用户的购物车表也不具有权威性。
只有当用户点击结帐时，用户的购物车内容才会影响库存可用性。只有在购买后才会实际库存减少。
最后一行提出了一个重点。可用品和库存品之间存在差异。由于网站的使用并发性，任何数量的人都可以在购物车中放置相同的商品而不会使其无法使用。
如果库存有10本Linux书籍，那么20人可以将1份副本放入购物车。前十个不是问题，但是第二个十个应该显示消息已售出？不。如果15个人走开，说从不介意，但从不清空他们的车怎么办？所有人都应该看到IN STOCK，但只有那些点击签出的人才会影响可用性。付费的人应该影响库存。
因此，在设置产品表时，请务必使用两个字段来跟踪产品：可用性和数量。它们是相关的，但在电子商务意义上它们并不相同。
最终注意： 在负载均衡的Web服务器方案中（亚马逊网络服务用户可能会同意），会话更有可能由数据库处理，因为它可以更容易地集中数据。虽然可以在NAS类型的解决方案上建立联网，集中和基于文件的/ NFS会话存储，但这可能是不可取的或最佳的（延迟，文件锁定问题）。