传统的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的各种限制和麻烦;
缓存验证,我现在的思路是,在更改商品数据的时候,要把更改的时间留下,每次获取数据库商品信息的时候,把最新的更改时间拿到,和数据一起缓存,验证缓存的时候,从数据库找到最新数据更改时间,和缓存做对比,一致说明数据没动过,不一致,就从数据库重新获取,再缓存!不知道您公司是如何的思路??求教了!!!