目前我们使用购物车的存储方式主要有：Session方式，Cookie方式，数据库存储， 现在来一一分析优缺点。

1.Session（Memcached）方式

优点：购物车信息保存在服务端，可以保存1M 信息。

缺点：对于大型网站会占有过多的服务器内存资源，造成服务器压力过大。Session保存的信息会在用户退出登录后丢失。用户下次登录，购物车中商品信息丢失，用户只能从新选择。

2.Cookie方式

优点：购物车信息存储在客户端，不占用服务器资源，基本可以到达持久化存储。

缺点：Cookie有大小的限制，不能超过4K，而且不够安全。如果是个人PC机，Cookie能很好的保存购物车信息，但如果是公共办公环境，Cookie保存的信息基本就失效了(会被其他人购物车信息覆盖)。对一个大型的电子商务网站，我们需要对用户的购买行为进行分析，需要对用户推荐用户感兴趣的商品，如果把购物车信息保存在Cookie中，则不能对用户购买行为分析统计。

3.数据库存储

优点：持久化存储，可以分析用户购买行为。

缺点: 网站速度变慢，成本和维护增加。

一般来说，可以使用session,cookie和数据库来记录购物车数据

1，不过不提倡使用session，这货占用服务器资源，还有过期时间，客户关掉浏览器时session即消失，下次再上来，又得重新选产品。

2，cookie这东西不错，放在客户端的，给个一年的过期时间，只要客户不清掉，每次来都能记得上次的购物车信息。大家可以看看京东，

在购物车cookie中存了不少东西，有产品编码和购买的数量等信息，如京东：yCartOrderLogic={&TheSkus&:[{&Id&:437741$&Num&:2}]}，

原来凡客的cookie中也以JSON的形式存了很多信息。

所以，我以学习的心态，将产品编码，价格，名称，类型和数量等购物信息做成一个对象，然后对象序列化成JSON，存在客户端的COOKIE中，

在读取cookie时，在刚开始的时候很好用，反序列化cookie值成购物车条目对象就可以了，但是当产品类型多起来之后，而且有套装那种多件产品时，

甚至产品不是来自同一个数据表时，比如普通首饰和钻石，表的结构都不一样了，还得到不同的表格中去取，当然首先你得判断产品类型

这时候一个购物条目对象已经有多条子对象，往往一个查询中嵌套着两重以上的循环加上多个switch case，当购物车中有十个复杂的条目时，读取速度

将超过十秒，不管怎么优化，速度就摆在那里，不快不慢。。。而且你不能保证客户不下100个或更多的复杂购物车记录，最重要的是cookie是有

存储大小限制的，这种做法有产品很复杂时是不利的，果断放弃！

3，数据库这东西好啊，不会像cookie那种容易丢失，也没有客户端的限制，你想怎么存，存多少都行。

购物车数据存数据库好处有很多，可以分析购买行为，可以为客户保存购买信息（不会因为浏览器关闭而丢失）等。

还需要考虑的一个问题是用户是否登录，淘宝使用的就是cookie记录，你可以试试，未登录时可以加20个商品，登录后可以加50个，这就是因为

cookie客户端的限制。

我这里因为产品线的复杂性，所有购物车条目都保存在数据库中。

购物车数据库设计成两个关联表

1，Basket，购物车主表

基本字段有：BasketId,AddTime,UserId,AddressId,Payment,Status等，不解释了，看英文意思就行

2，BasketDetail，购物车条目表

基本字段有：BasketDetailId,BasketId,Type,Code,Qty,ParentId等，ParentId用作子行标识，其它不解释

两个表之间使用BasketId做为关联

当用户登录状态时，添加产品到购物时，查看Basket中是否有Status为True的购物车，没有则添加一条新的Basket记录，并将产品信息相关数据添加至BasketDetail表中

当用户未登录时，使用cookie记录一个BasketId值，不往Basket表中插入数据，只往BasketDetail插入数据，其中的BasketId值使用cookie中的BasketId值，当用户登录

后，查看Basket中是否有Status为True的购物车记录，有则合并（更新cookie和BasketDetail中的BasketId为查询出来的Basket表中的BasketId值），无则添加一条新的

Basket记录，并将BasketId值置为Cookie中记录的basketid值.