欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  php教程

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

程序员文章站 2022-05-26 10:41:50
...

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

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

王于萍:

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

比如供应商管理,你会得到供应商的公司地区、电话、类目等,在数据统计中,你可以对地区、类目统计,再根据C的对应需求推荐等

PalmWong

建议先从业务理解开始:

BBC平台,首先分成三个后台

商家门户+平台运营门户+买家个人门户

要做统计的部分同样是三块:

1、消费者个人视角出发:个人的消费统计

2、平台运营的视角出发:整个平台的运营情况统计,针对商家的运营情况统计

3、商家视角出发的统计

BBC商城其实是非常复杂的业务系统,因为角色和功能的变化,导致其中数据交互其实非常多。且对账、统计、权限管理异常情况很多。

不是看着天猫的模式,就闭着眼睛可以做的。

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

Dion

系统架构很重要!

语言:

主流语言都没什么问题。PHPJava什么的都行。

前端服务器:

如果有条件CDN,最好。没有的话,一定要保证前端的负载性能。一般推荐Nginx

应用服务器:

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

数据存储:

如果数据量比较大的话(百万级),用MySQL + Memcached做集群没问题。

如果数据量再大的话,考虑NoSQL吧。比如FacebookCassandraAmazonDynamo

socici

你可以简单点,从用户访问的数据角度看

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

通过前后台发布的动态数据,分以下几种:

读的数据:

1.需要用户查询的大数据,如订单之类的,可以去查slaver的数据库

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

写的数据:

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

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

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

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

例如:1 手机、100

规格表(主键、商品ID、规格名称

例如:1 1、运营商

商品规格值表(主键、规格ID、商品ID、规格值ID、规格值NAME

例如:1110、电信版

2111、移动版

规格库存表(商品ID、规格值ID组合、规格值NAME组合、库存量、价格)

例如:11/0(运营商、电信版)、运营商/电信版、100个、100

问题描述:

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

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

需要的帮助:

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

socici

商品分类 (类型id,类型名称,父ID

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

规格表(主键、规格名称

规格值表(规格值ID、规格id、规则值类型、规格默认值)

规格-分类关联表(商品分类id,规格id)

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

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

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

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

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

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

刘传双:

总体来说

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

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

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

4、文档在存储之前,先保存图片,并把文档中[产品设计]电商设计知乎总结,产品设计电商总结的图片src地址替换为小文件系统中的图片路径,就可以了

补充一句,不能把存储理解成只有数据库和文件系统,存储有各种类型的,不同的文件系统、各种RDBMSNoSql存储……

子柳:

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

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

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

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

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

相关标签: 用户体验