电子商务::购物车::我应该在会话或数据库中存储购物车数据

Question

我应该在哪里将购物车数据存储在会话或数据库中？(我认为在用户注销后的amazon.com购物车中,并在一个月后再次登录他在购物车中选择的订单保存)谢谢,Yosef

Answer 1

当然购物车数据是关键数据.保存此数据的位置取决于您的电子商务系统所使用的用户.

1. 使用未签名(尚未)用户 - 您必须将此数据保存在Web存储上,html5使您能够使用前端存储,这适用于任何浏览器(Cookie,会话存储,本地存储).在结账过程中,系统必须要求用户注册.注册后,您必须将此数据与数据库同步.否则,您不必在Database上保存此无法追踪的数据.

2. 使用签名用户 - 当然是在数据库中.通过这种方式,您可以正确跟踪用户的篮子.如果用户将从您可以向其显示其帐户和"待付款项目"的任何位置登录.将这些数据保存在浏览器存储中取决于您的口味.

这些信息也可能对客户端和服务器端购物卡存储有帮助

Answer 2

我在这里展翅高飞。制作一个灵活/逐步增强的购物车。

未登录

计划 A）如果使用 Web Storage，使用它（会话存储/本地存储），因为知道所有客户的购物车数据也可以使用 AJAX 聚合到跟踪购物车数据库表（带有时间戳和会话 ID）中。同步和修剪是关键（客户端、跟踪表）。不需要单个购物车数据的服务器端会话存储。

如果浏览器关闭，可以重新建立购物车。优雅地关闭浏览器应该会导致一个 AJAX 调用来修剪跟踪表。

跟踪购物车不具有权威性（用于影响/保留库存），因为它不代表处于付款边缘的已识别客户。只有当客户点击结账时，跟踪购物车中的物品才会对库存产生影响（不过还有更多工作要做）。

计划 B)否则，只回退到 [服务器端] 会话 cookie 的逻辑。使用 AJAX 读取/写入集中购物车跟踪表中的数据。客户端从不存储单个购物车数据，也不存储在会话数据中（数据库驱动，或非数据库驱动）。只要客户未登录，他们的购物车数据仅在集中跟踪购物车中。

如果浏览器关闭，客户端购物车将永远丢失。如果浏览器正常关闭，项目也将使用 AJAX 调用从跟踪表中删除。否则，数据库中的旧购物车数据将通过活动时间戳进行修剪。

替代计划 B)使用标准的加密 cookie 实施持久的客户端解决方案。这样，无论浏览器是否正常关闭，都可以重新建立客户端购物车并更新跟踪购物车表。这将支持较旧的用户代理，并以进行更多编程和测试为代价为他们节省一些挫败感。

注意：您必须预测并处理会话 ID 将在会话的整个生命周期中更改的现实。如果您想避免会话固定，您不能对每个 HTTP 请求一遍又一遍地使用相同的会话 ID。因此，您必须在每次请求时更新主跟踪表中的会话 ID。* 如果许多用户未登录并且他们的购物车中有许多产品，这可能是大量更新。

登录

当客户登录时，您将他们的跟踪购物车内容复制到他们自己的购物车表（常规表，不在会话中）。shell 游戏现在将在客户端、购物车表数据和主跟踪车之间进行。无论用户代理如何，用户的购物车内容现在都是持久的。用户的购物车表也不是权威的。

只有当用户点击结账时，用户的购物车内容才会影响库存可用性。只有购买后，实际库存才会减少。

最后一行提出了一个重要的观点。可用和库存之间存在差异。由于网站的并发使用，任何数量的人都可以将相同的项目放入他们的购物车而不会变得不可用。

如果库存中有 10 本 Linux 书籍，则 20 个人可以将 1 本书放入他们的购物车。前十个没有问题，但后十个是否应该显示一条消息 SOLD OUT？不。如果 15 个人走开，说没关系，但永远不要清空他们的购物车怎么办？所有人都应该看到 IN STOCK，但只有那些点击结帐的人才会影响可用性。支付者应影响库存。

因此，在设置产品表时，请确保有两个字段用于跟踪产品：可用性和数量。它们是相关的，但在电子商务意义上它们并不相同。

最后说明： 在负载平衡的 Web 服务器场景中（Amazon Web Service 用户可能会同意），会话更有可能由数据库处理，因为它可以更轻松地集中数据。虽然可以在 NAS 类型的解决方案上拥有网络化、集中式和基于文件的 / NFS 会话存储，但这可能不是可取的或最佳的（延迟、文件锁定问题，更不用说安全配置）。

Answer 3

两者怎么样？阅读购物车数据时,请先检查您的会话.如果它存在,则保存到数据库的行程(如果您的会话没有数据库支持).写入时,写入会话并持久保存到数据库.这样,您可以获得快速读取,并且用户在关闭浏览器时不会丢失购物车.