HTTP会话或数据库方法


16

我对应该采取的方法感到有些困惑,正在研究购物车的设计,我需要将购物车存储在会话中或数据库中,但不确定哪种方法是最佳方法。

  1. 用户未登录并将产品添加到购物车(匿名用户)
  2. 用户已登录并将产品添加到购物车。

第一种情况对我来说更令人困惑,因为在许多情况下,用户只是访问网上商店并在没有登录的情况下添加产品,很可能他可能不会进行结帐流程。

但是我们仍然需要为此用户创建一个购物车,为了创建和保存购物车,我有两个选择。

  1. 当用户添加产品时,请在数据库中创建一个购物车并将该购物车与该用户相关联,当他登录时将其移动到登录用户。
  2. 当用户登录数据库中的创建购物车并将该登录购物车的用户与用户相关联时,创建购物车,向其中添加产品并将其保存到会话中。

我知道无论是数据库驱动的Cart系统还是基于Session的方面都可能有积极的方面也有消极的方面,但是我不确定哪一个是考虑以下几点的最佳方法

  1. 可扩展性
  2. 灵活性
  3. 可扩展性
  4. 应用程序应注意速度

寻找有关此方面的信息以决定路径。


2
为什么?我经营着数百个电子商务网站,我们将所有内容都存储在Cookie或localStorage(HTML5)中。此外,会话会占用内存。进行帐户登录时,我们使用带有时间戳的加密cookie。我们不需要会话,因为在页面加载时,我们使用HTML5技术在一次加载后存储和使用sessionStorage。这是IE8 +兼容的标准网络技术。
杰森·塞布林

@LuiggiMendoza好吧,为什么不呢。
杰森·塞布林

@ zipstory.com:我也想看看基于HTML5的解决方案,但是仍然由于很少的浏览器不支持它,我有点怀疑
Umesh Awasthi 2013年

@UmeshAwasthi我想我的客户并不关心少数几个使用较低版本浏览器的人,但是如果您的网络流量情况不同,显然这是一个不好的方法。我知道世界上仍然有很多人在IE7和IE6上使用XP,但是我的一些客户产品在商店(如Nordstroms和Macy's等)中都可以找到,似乎并不担心。
Jason Sebring

@ zipstory.com:我正在使用一个电子商务应用程序,客户甚至希望支持IE6,现在您会说::
Umesh Awasthi

Answers:


9

我将寻求一种解决方案,在所有访问者首次访问该网站时为其分配唯一的ID。它们是匿名的还是经过身份验证的都没有关系。匿名用户注册时,保留唯一ID。

将购物车存储在数据库中。存储很便宜,并且时不时地查询购物车在性能方面也不是问题。


我何时需要显示购物车详细信息页面怎么办?我们应该存储/从会话中获取数据还是去数据库命中?
Umesh Awasthi 2013年

如果您将购物车详细信息存储在数据库中,则可以,您需要点击数据库。
2013年

7

两种方法都有优点和缺点,但是从我的角度来看,数据库存储有两个很大的优点。

  1. 正在报告。如果数据在会话中,则无法报告废弃的购物车,转化率等。
  2. 会话超时。如果我去吃晚饭并回来找我的购物车是空的,那会很生气,因为会议已经过期了。我想零售商也不会那样。我们希望将用户推向购买,而不是放弃并离开。

6

问题是,假设您根本需要举行会议,而在我的客户市场中则不需要。我碰巧经营着数百个电子商务网站,其中一些网站的流量很高。我们不会使用会话,因为它们无法扩展,除非将其拖出便会变得更慢或需要更多设置。会话用尽了内存,数据库对会话状态的获取非常缓慢,并且需要更多的活动部件。

取而代之的是,我们使用HTML5 sessionStorage来持久存储需要一次又一次拉出的所有用户信息,而无需每次都进行cookie漫游以增加带宽。这是IE8 +,所有其他现代浏览器和移动设备都与此技术兼容。但是,您可以轻松地将购物车存储在cookie中作为后备,因为这是我们之前所做的。这是一个很好的cookie推车:http : //simplecartjs.org/

用户登录或登录时,我们使用带有时间戳的加密cookie。

我们还将努力在适当的地方使用ApplicationCache,这将进一步减少Web流量,因为您可以预取资源甚至目录数据,因此用户角度将是一个超快速加载的网站,而移动设备也将脱机工作(减去交易)。当然,当产品变更等时,您必须小心更新清单。


4

您假设会话存储和数据库存储是互斥的。他们不是。但是,让我们从假设它们开始。

会话存储的优点有三方面:

  1. 无需将数据显式插入数据库。您只需要简单地设置一个会话变量就可以了。功能简单且低风险。
  2. 无需管理用户访问和购物车的生命周期,因为容器/框架可以帮助您
  3. 通常,您会自动清除旧的空闲会话。

会话存储的缺点:

  1. 会话亲缘关系,除非您调查复制
  2. 除非进行调查或将会话状态手动保留到磁盘,否则不会进行故障转移,否则可能会变得很复杂。
  3. 所有会话必须存储在内存中。如果使用复制,则会放大。

数据库存储的优点:

  1. 无需担心会话亲缘关系或状态复制。您可以轮询所有请求。
  2. 减少应用程序中的内存开销。
  3. 如果订单完成,无论如何一切都将最终存储在数据库中,因此可以轻松完成,因为数据已经存在。

数据库存储的缺点:

  1. 废弃的购物车-一些匿名用户向其购物车中添加了商品,然后消失了。除非您有某种到期过程,否则该数据将永远存在。
  2. 您需要想出一种方法来跟踪用户,并弄清楚对于给定的请求,这表示是现有的浏览会话还是新的浏览会话。(是的,如果您使用cookie,这可能很容易,但是如何确保两个用户的ID不相同?)。
  3. 更多代码

您没有提到您使用的平台。我将寻求一种使用数据库支持的会话的方法,其中会话数据仅在请求/响应周期的生命周期中存在于内存中,然后从数据库加载并保存回数据库。过去这对我很有帮助。

数据库支持的会话的优点:

  1. 无需服务器关联。
  2. 轻松存储在应用服务器上
  3. 空闲/已放弃的会话数据将为您清除。
  4. 用户首次访问,重复访问,会话结束的生命周期都已为您找到。
  5. 易于编码

数据库支持的会话的缺点:

  1. 配置-您需要研究容器,无论它是PHP,Java EE(Tomcat,Jetty,JBoss等),node.js + express.js还是不支持此容器的容器,并提供正确的配置。
  2. 您可能需要对此进行负载测试,因为每个请求要添加2个数据库操作。

还有第三种可能性,有人在前面提到过。您可以将所有内容都嵌入Cookie或html本地存储中,从而完全跳过会话的使用,而使用客户端存储。

我将把它的优缺点留给您练习,但我会向您暗示,对于html5存储,浏览器的兼容性可能需要仔细检查。

我已经为您概述了事实。希望这可以帮助您根据情况做出正确的决定。


您错过了数据库存储的优势,无法灵活地分析组织放入购物车中商品的购买率。
HLGEM 2013年

@HLGEM好主意-我从没想过!
布兰登

我之所以这么想是因为我是负责数据库数据分析的人。在设计数据库时,首要问题之一应该是我们将需要什么数据,而几乎没人问过。
HLGEM 2013年

3

让我们考虑您提到的两个用例

用户未登录并将产品添加到购物车(匿名用户)

在这种情况下,您肯定要在会话中保存用户的购物车信息,以便在用户会话期间为用户提供良好的服务。如果他/她确实决定登录/创建帐户,则可以根据下一个用例进行处理。如果他/她没有登录,则您不需要用此访客用户的信息填充数据库,因为该信息仅在会话期间用于为访客提供服务。可以在无状态的基础上处理此数据,即不是在会话之间不保存状态。

用户已登录并将产品添加到购物车。

在这种情况下,您可以采用与上述方法相同的方式(旧式电子商务网站)进行处理,并将此信息添加到数据库中并将其与用户相关联。这主要用于提供有状态(从会话到会话保存的状态)信息,例如“产品浏览历史记录”,“建议”等,即类似于Amazon.com。

要考虑的事情:

  • 是否需要保存数据?
  • 如果是,保存哪些数据对于更好地服务用户最关键?
  • 可扩展性+数据存储-如何将购物车信息保存在数据库中以便快速查找,以支持许多用户?

3
它还可以帮助公司分析销售情况。产品多久被放入购物车中而不被购买。如果百分比很高,那么他们可能希望查看产品的展示方式或价格,以查看更改是否可以帮助提高购买率。保存后,如果用户当天没有订购商品而不是再次寻找商品,则可以使用户快速查看这些商品。因此,也许您将它们放在购物车中,但想等到明天(发薪日)才能实际购买它们。因此,保存数据可能会导致您的实际客户购买更多东西。
HLGEM

但是最后这是一个需求定义问题,您应该在构建任何东西之前告诉您的企业您打算做什么,并确保它是他们的期望。
HLGEM

记住,您需要从业务将来可能需要数据的角度考虑订单和购物车。如果他们想分析数据,最好将其存储。开发人员在用户界面上挂了电话,在设计时忘记了存储数据的目的。
HLGEM

@HLGEM:非常好!我仅基于支持来宾用户和站点成员支持汽车功能的需要回答了这个问题。从商业的角度来看,应该有一个独立的统计系统是依赖于某种数据库系统是轨道产品(第)在地理,用户#而言,相关产品的购买与丢弃等
GeekByte

0

当用户未登录时进入会话。即使登录,也要在会话中首先创建购物车,并仅在用户注销或会话超时时将其保存到数据库中。

您需要检查在会话中创建的购物车数量。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.