[产品设计]电商设计知乎总结

 

想作一个B2B2C的电商平台，在后台数据统计搭建的时候须要注意哪些问题？如何设计具体的统计模块？

 

王于萍：

我认为在建数据库前，须要设计好的，是需求和流程，有了这一步的需求，你就知道了在这里你须要什么数据；有了流程，你就知道了你能获得什么数据，甚至于数据类型。

好比供应商管理，你会获得供应商的公司地区、电话、类目等，在数据统计中，你能够对地区、类目统计，再根据C的对应需求推荐等

 

 

PalmWong：

建议先从业务理解开始：

BBC平台，首先分红三个后台

商家门户+平台运营门户+买家我的门户

 

要作统计的部分一样是三块：

1、消费者我的视角出发：我的的消费统计

2、平台运营的视角出发：整个平台的运营状况统计，针对商家的运营状况统计

3、商家视角出发的统计

 

BBC商城实际上是很是复杂的业务系统，由于角色和功能的变化，致使其中数据交互其实很是多。且对帐、统计、权限管理异常状况不少。

 

不是看着天猫的模式，就闭着眼睛能够作的。

 

用 PHP+MySql 架构用户数和访问量为千万级别的相似淘宝商城那样的 B2C 网站，如何？

 

Dion：

系统架构很重要！

 

语言：

主流语言都没什么问题。PHP、Java什么的都行。

 

前端服务器：

若是有条件CDN，最好。没有的话，必定要保证前端的负载性能。通常推荐Nginx。

 

应用服务器：

集群呗。前端负责负载均衡。集群的话，Session的问题注意下就行。别的没什么。

 

数据存储：

若是数据量比较大的话（百万级），用MySQL + Memcached作集群没问题。

若是数据量再大的话，考虑NoSQL吧。好比Facebook用Cassandra，Amazon用Dynamo。

 

socici：

你能够简单点，从用户访问的数据角度看

静态文件,包括图片、HTM 、JS、css 这些不常常变的数据。 单独给个域 如http://static.xxxx.com 由nginx管理

经过先后台发布的动态数据，分如下几种：

读的数据：

1.须要用户查询的大数据，如订单之类的，能够去查slaver的数据库

2.系统公共页面显示的数据，如部分商品信息、排行榜之类的能够去缓存里取

写的数据：

要求即时生效的，如修改用户信息，直接同步写到master数据库

即时要求不高或者有并发限制的，如发微博、发私信之类的 先写到队列，异步读取保存到数据库

 

电商平台中商品规格设计的问题，抛出，求吐槽？

 

商品表（商品名称、价格、上下架等一些商品基本的信息）

例如：1、 手机、100

规格表（主键、商品ID、规格名称 ）

例如：1 、1、运营商

商品规格值表（主键、规格ID、商品ID、规格值ID、规格值NAME）

例如：1、1、1、0、电信版

2、1、1、1、移动版    

规格库存表（商品ID、规格值ID组合、规格值NAME组合、库存量、价格）

例如：1、1/0(运营商、电信版)、运营商/电信版、100个、100块

 

问题描述：

 

以上方式可实现多规格多库存可是采用一种约定的规格顺序，感受在编写程序时，系统在后期统计不一样规格相关的数据就会很痛苦。

而且在实现商品建立时，要先把商品建立好后，才能建立规格，我的参考一些大的电商平台方式，发现都是一个提交完成商品建立。

 

须要的帮助：

 

须要结合个人问题描述，给一个合理的商品多规格、多价格、多库存的设计方案，来解决我编程上的复杂度，同时保证我能够在商品建立的交互设计中简单。

 

socici：

商品分类 （类型id,类型名称，父ID）

商品表（商品名称、价格、上下架等一些商品基本的信息、商品分类）

 

规格表（主键、规格名称 ）

规格值表（规格值ID、规格id、规则值类型、规格默认值）

规格-分类关联表（商品分类id，规格id)

 

商品-规格关联表(商品id,规格id,规格值ID,规格实际值）

 

库存表（商品id,数量,价格)

 

相似淘宝关于产品详情页的数据库存储是怎么存储的呢？

 

1，每一个产品的 图片数和介绍的段落数都是不固定的,是采用编辑器编辑好以后生成html整个存储到数据库么？不现实吧？

2. 要是以数据库字段存储到话,每一个产品的 图片数和介绍的段落数是不固定的,就算设置一个上限,那也会浪费不少字段啊

3.在查询的时候,若是图片和介绍文字是分开存储的,那么在查询以后页面展现的时候是怎么 将某一图片和关于介绍他的问题相匹配的呢

 

刘传双：

整体来讲

1、商品的结构化信息保存在数据库，名称、价格、库存、属性等，固然不是简单的一张表。

2、商品的非结构化信息保存成小文件，存储在自主开发的海量小文件系统中，图片和商品描述信息。

3、商品的图片文件id须要存储在数据库或者其余类型的存储的，不必定非要多个字段，这是水平方式，通常把商品的一个图片存储为一条记录，纵向扩展。

4、文档在存储以前，先保存图片，并把文档中<img>的图片src地址替换为小文件系统中的图片路径，就能够了

 

补充一句，不能把存储理解成只有数据库和文件系统，存储有各类类型的，不一样的文件系统、各类RDBMS、NoSql存储……

 

子柳：

其实几位同事已经回答了，我再从历史的角度作个补充

最先这个字段确实是放在数据库里面的，是一个clob字段，存放的就是html的片断。并且当时这个字段跟商品的标题、价格、卖家ID等等是在一个表里面的，性能会受到多大影响是能够想象的。

因此这种方式是注定长久不了的，我在2005年，把这个字段单独分离出来一张表来存放了，这没多少技术含量，当时却给数据库减轻了很大压力，DBA们很感谢我。

在2006年之后，淘宝开始大规模的采用缓存，这个字段也放进了缓存里面，因而这又给数据库减轻了很大压力（只有不在缓存里的数据，才去数据库里面读取，读出来就放入缓存了）。

到了2007年，淘宝开发了分布式文件存储系统TFS，因而就完全的把这个字段请出了数据库，一同请出的还有交易快照这样的大字段信息。