本身在电商系统就非常的复杂,他们里面的表也相对来说扩展性都很强,关于里面的表设计有很多需要推敲学习的地方,这里我们一起从最复杂的商品模块着手,一起了解下商品模块业务的设计。电商平台上涉及到非常多的产品,这些产品五花八门,从书到电器,从衣服到家具,等等等等,书有出版社,衣服有颜色,手机有容量,属性根据产品的不同也差别极大,对于我们而言又需要如何去抽象这些概念,如何去设计数据库?
我相信大家应该都在淘宝或者京东上进行过购物,电商平台基本都用过。
1.商品的资料(比方:卖什么手机,手机的一些资料)
2.商品的图片处理(拍照,ps特效等)
3.商品发布
4.商品维护(商品库存的更新,商品图片,属性的修改,促销价格修改)
5.商品下架(卖的比较好,断货了需要下架)
商品分类+商品信息
问题:举个场景:apple可以水果,也可以是手机,用户无法区分是找水果还是找手机。最小单元不明确,太宽泛,不能很好的定位。这也是淘宝第一个版本。
商品分类+商品信息+品牌,区分分类
问题:就算有了品牌,但是缺少属性列表找起来还是有点费劲的。例如:华为的我想找,翻盖的,支持5G的,虽然有了品牌,但是找起来还是很费劲的。
属性 + 商品分类 + 商品信息+品牌
问题:不同的商品,里面的属性不同,例如:鞋子,属性里面有尺码的概念。手机,属性分类是双核,多核。
商品分类,属性,品牌,商品信息,属性扩展表。
商品分类-----属性 (多对多) 一个分类有
属性------属性扩展表(多对多)
商品------ 扩展属性表 (多对多)
加入规格的概念,规格是对商品分类。
SPU = Standard Product Unit (标准化产品单元)款
SKU = Stock Keeping Unit(库存量单位) 件
参数 | 名称 | 类型 | 备注 |
---|---|---|---|
id | 自增长 | int | 唯一 |
name | 分类名称 | String | |
code | 编码,简码 | String | 唯一 |
pid | 父ID | Int | |
order1 | 排序 | Int | |
type | 类型 | String | 类型,a:文章目录;p:产品目录 |
showInNav | 是否显示在首页的导航条上 | String | y:显示,n:不显示;默认n。仅对type=p有效 |
参数 | 名称 | 类型 | 备注 |
---|---|---|---|
id | 唯一,商品ID | int | |
catalogID | 商品类别catalog表id | varchar | |
name | 商品名称 | varchar | |
introduce | 商品简介 | text | |
price | 定价 | DECIMAL(9,2) | |
nowPrice | 现价 | DECIMAL(9,2) | |
picture | 小图片地址 | String | |
score | 赠送积分 | Int | 0 |
maxPicture | 大图片地址 | String | |
isnew | 是否新品。n:否,y:是 | String | n |
sale | 是否特价。n:否,y:是 | String | n |
activityID | 绑定的活动ID | String | |
giftID | 绑定的礼品ID | String | |
hit | 浏览次数 | int | 0 |
unit | 商品单位。默认“item:件” | String | |
createAccount | 录入人账号 | String | |
createtime | 录入时间 | datetime | |
updateAccount | 最后修改人账号 | String | |
updatetime | 最后修改时间 | String | |
isTimePromotion | 是否限时促销。n:否,y:是 | String | n |
status | 商品状态。1:新增,2:已上架,3:已下架 | Int | 0 |
productHTML | 商品介绍 | LONGTEXT | |
images | 商品多张图片集合,逗号分割 | String | |
sellcount | 销售数量 | Int | 默认:0 |
stock | 剩余库存数 | Int | 默认:0 |
searchKey | 搜索关键词 | String | |
title | 页面标题 | String | |
description | 页面描述 | String | |
keywords | 页面关键词 | String |
查看苹果所有的产品(手机苹果、电脑苹果)需求
更加快速找到我们想购买的商品
参数 | 名称 | 类型 | 备注 |
---|---|---|---|
id | 自增长 | int | 唯一 |
name | 属性/参数名称 | String | |
catalogID | 类别ID | Int | |
pid | 父ID | Int | 该字段具有双重含义。0表示属性大类,一般情况下产品只有两层attribute,一层为属性名称类别,一层为属性;-1:参数 |
order1 | 排序 | Int |
参数 | 名称 | 类型 | 备注 |
---|---|---|---|
id | 自增长 | int | 唯一 |
attrID | 属性(参数)ID | Int | |
productID | 商品ID | Int | |
value | 商品参数值 | String | 名称从属性表中取得 |
t_spec商品规格表
参数 | 名称 | 类型 | 备注 |
---|---|---|---|
id | 唯一 | int | |
productID | 商品ID | String | |
specColor | 颜色 | String | |
specSize | 尺寸 | String | |
specStock | 此规格的商品库存数 | Int | |
specPrice | 此规格的商品价格 | Double | |
specStatus | y:显示规格;n:不显示规格 | String |
ES、SOLR (数据源来自数据库,那就意味着同步)、分词
商品+图片+库存+店铺+商品相关的信息
GFS、TFS、FastDFs 底层原理?特点:文件小、图片小
查询的速度、内存》硬盘(数据源来自数据库,那就意味着同步)
增加、修改、下架
预热数据(某个活动所有商品加载缓存中)
把html+CDN
更新上需要更新HTML
PS:商品表的设计比较复杂,里面设计的技术点主要是展示和缓存,静态化,电商主要就是交易,商品。