商城平台中,商品表的架构设计探讨。
发布于 4 年前 作者 juan61 4211 次浏览 来自 分享

传统的mysql商品表的设计结构里,一般会先有一个分类表,然后在商品表中关联该分类,这样的结构主要沿于mysql的表设计理念,与小程序云数据库的设计理论并不完全相配,有一些弊端:

1、分表。与nosql不符;

2、在小程序里联表lookup是比较麻烦的,需要通过云函数才能实现;

3、影响效率;

我们对这种设计方式进行了改动,只需要一个product表,实现商品分类和商品详情合二为一表;

表结构如下:

product:{
tag:'水果',//一级分类
tag2:'热带水果',//二级分类
name:'香蕉',
...//其他
}

获取分类:

aggregate().group({_id:"$tag"})得到所有一级商品分类;

aggregate().group({_id:{tag:"$tag",tag2:"$tag2"})得到一级分类和二级分类的组合

aggregate().match({tag:'水果'}).group({_id:"$tag2"})得到水果下面的所有二级分类

实践应用中发现这样有不少好处:

1、只需要一个页面来实现新增商品功能,增加商品的时候,只要任意输入tag就行,等于自动创建了一个新的分类;

2、删除商品的时候,不会出现某个分类里商品数量是0的情况;

3、通过aggregate().group()可以一次获取全部分类以及每个分类下的全部商品列表,避免limit为20的各种限制和麻烦;

4 回复

缓存验证,我现在的思路是,在更改商品数据的时候,要把更改的时间留下,每次获取数据库商品信息的时候,把最新的更改时间拿到,和数据一起缓存,验证缓存的时候,从数据库找到最新数据更改时间,和缓存做对比,一致说明数据没动过,不一致,就从数据库重新获取,再缓存!不知道您公司是如何的思路??求教了!!!

补充一下:

每个分类可能需要一个icon,因为商城首页一般会有分类展示,需要一个icon和一个分类名,我们是怎么处理的呢?我们自动把该分类的最新一个商口的封面作为分类的icon。

好处有:

1、分类icon永远都是新的,经常变化,但又非常符合分类名,感觉体验不错;

2、不需要为每个分类上传一张图片了。

能写下 ‘通过aggregate().group()可以一次获取全部分类以及每个分类下的全部商品列表’ 的具体代码么?

关注你了!特来点赞!

回到顶部