刚看到吴磊同学的一些关于购物车的想法，正巧本人丁学对电子商务这方面比较熟悉，跳出来献丑了，希望对一些同行有些用途。本来想回复到下面的，结果发现写起来比较多，干脆写到这里好了，当前本人找起来也方便，呵呵

问题： 1.购物车中的数据能否应该存储在数据库中？
我特别想知道在真正的项目中，那些真正的软件工程师是如何考虑这个问题的。在Google上一搜，搜到了一篇咱园子里一位网友的观点：购物车应该是个临时存储数据的模块，他将其存放在Session对象中。这位网友说的很有道理，不过我并不喜欢这样的做法。如果大家都将其存储在Session对象中，成千上万个用户一同购物的话，想必ASP.NET服务器必将承受巨大的负载。也许像我们国内的网站可能会好一些，但想Amazon这样的网站，怎样做的呢？Amazon中国网站，也就是Joyo的网站，并不是将其存储在Session对象中，由于我如果这次放入购物车中的商品没有提交订单，下次登录后购物车中还会有这些商品。因此，我想他们可能是将这些购物车中的数据放入了数据库中。

回复： 把购物车存放在Session中，这种做法似乎只存在于大学里的课程设计或者一些无人在意的实习项目中出现。理想上，基本所有的电子商务网站都把购物车数据存放到了数据库里。下面是一些解释和设计上需求留意的地方：
1、Session并不适合做大数据量的数据存放，当用户比较多的时候势必影响服务器功用，这是应该避免的。
2、Session存在不测丢失的问题，或者当用户不小心关闭浏览器，都会惹起购物车内物品全部丢失，用户体验很不好
3、Cookies可以处理上面一条里Session的问题，但是Cookies的长度限制，以及使用Cookies时的通讯开销，还有安全性方面考虑，Cookies并不适合做购物车
4、比较好的用户体验是，无论用户登录与否，都可以在一定时间内记录购物车形状，这就要求数据库内购物车不能与用户捆绑太死
5、放到购物车里的商品，普通都是有购置意向的商品，但并不一定会成为真实的订单，这时候，保留这份数据，对数据挖掘、业务分析有至关重要的作用

问题： 2.关于并发？
原来我在开发本人的模仿网站的时候，曾经想到这样一个问题：如果一个客户在网站将一些图书放入了购物车，那么这些数量的图书能否应该从库存中减去呢？当时我是这样做了。我将购物车中相应图书的数量从数据库中减去，以防止此时其他用户看到”虚”的库存数量（如果没有减去，那么其他用户是可以购置的。例如：库存中图书的数量是10本，客户A将10本放入本人的购物车，此时客户B也将10本放入本人的购物车，那么谁将购置到此书将成为一个矛盾）。不过我这样做的结果是，每当客户更新购物车的同时就会同数据库有一次交流，加大了数据服务器的负担。Amazon.cn在这方面做的也不是很好，前些日子置信大家可能都遇到了当购置《深入理解操作系统》一书的时候，本来生成了订单，但是却在第二天告知缺货的事情。这一事件确实非常影响Amazon.cn的信誉，不知道如今他们的系统能否曾经处理这一问题，不过如今《深入理解操作系统》一书的Joyo价曾经今非昔比了。不知道各位高手是如何处理这一问题的，欢迎大家将本人的成功经验写在评论中。

回复： 首先说一下数据库服务器的负担，想一下每访问一个页面要对数据库进行多少次访问，然后想一下多次访问才能换来一次放购物车的操作（访问次数次要取决于网站易用性的设计，这是另外一个话题），所以，虽然在这里修正设计可以减轻一些数据库压力，但是这里并不是瓶颈，丁学认为不需求在这里太在意。

目前比较通用的做法，购物车的商品是不会立即扣减库存的，次要是为了防止有人通过购物车恶意占用商品，另外普通都会给一个冗余量，由于大部分购物车里的商品不会进入最终的成功订单，不可以让购物车影响销量，这是必须做到的。库存普通在订单成功提交的时候扣减库存，也就是用户在提交订单时，你还有一次机会提示用户没有库存了，所以更没有必须在放到购物车时就扣减库存。对于“成功订单”，并不是所有用户提交的订单都算成功订单，这里有一个自动审单的过程，这个程序不好写，但确实很重要，依据以前的数据分析、用户行为、用户信誉等经验性的数据来由系统在几分钟内自动对订单完成一次审核，审核力度与行业有关，这样可以杜绝大部分的假订单，其中一部分可能还要由自动审单系统转交人工审核。

这里有一个特殊情况，有一些特殊商品比如演唱会门票，可能会存在在线选座的行为，这种时候放购物车后留座变得比较有用，如今的做法普通是放购物车后立即留座，但某一段时间未成为真实订单的话就自动释放，比如十分钟，虽然无法完全杜绝恶意占座，不过可以处理多数问题。如今票务方面的成功订单和大部分其他行业不太一样，票务行业的在线选座成功订单的判断标准为能否曾经成功领取，就是说除非你给钱了，不然只能给你留十分钟。

问题： 3.订单和订单明细同购物车的关系
我想这个问题可能不断是此类网站的一个大问题吧！前两天，CSTP的陈老师还曾在电话中面试我这道题，我当时很紧张，问题答的不是很清楚。其实这个问题简单的想并不难：两个表订单和明细，订单表中每列指向明细表中的对应列。外键就是订单表中的订单号。

回复： 这个问题比较简单，一种是放购物车里就当是订单了，拿一个形状标识一下，这种形状下订单是可修正的，购物车合并进订单系统（留意处理用户登录与非登录形状）；第二种是有单独的购物车表，当最终提交订单时，复制购物车内的信息进订单和订单明细表。后一种用得比较多一些，具体选择哪个取决于行业和商品属性。

问题： 4.明细表中订单号的生成？
这个问题承继第3个问题，我不断不知道应该如何处理此问题。我有两个处理方案，一个是使用触发器，另一个是编程。前者在客户每次放入购物车中一种商品的同时添加一个明细，确认购置后生成订单，将明细表中的购置形状更改以触发触发器将生成一个订单号（当然这个订单号既可以在触发器中编程也可以是让订单表订单号的一列设置为自动生成序号）。后者将判断订单号，然后将其加1以生成新的订单号。但是这两个方案我总是觉得非常不好，很想知道在商用网站中订单号是如何处理的。

回复： 首先我团体认为触发器的方案不可取，理由不多说，不然又是一大坨。这里也有两种做法，一种是订单表自动生成编号，生成订单时，先写入订单表，然后取回订单号再更新订单明细表；另一种是按业务规则生成订单号，当订单号已知后随便先生成订单记录还是明细记录都可以，但是要保证明细记录最终一定有订单记录，不然会有很多诡异的明细项。后一种办法又有两种做法，一是订单号由数据库生成，普通采用临时表，好处是可以全业务通用流水号，另一种是订单号由程序生成，程序生成时可以使用GUID，但更好的办法是使用订单时间加标识值，时间部分可以依据订单量来确定粒度大小，标识部分采用有序编号，时间粒度还要考虑防止别人大概统计你的业务量（汗~~~这个也是另外的问题，很多做法，看情况了，改天有空再写个有关订单号生成的文章吧，先回复这么多，大概信息也够了……）