服务器数据库模型是先有一个User集合,存储用户信息,然后用户登录之后,要获取自己的Shop信息,然后还会根据Shop信息,获取每个Shop下面的Category商品分类信息,然后根据Category找到对应的Product信息。大概就是有这样的业务逻辑。这样就必须要创建User,Shop,Category,Product这四个集合了。我们服务器采用的方案是Nginx+uWSGI+flask+Mongodb。以上陈述完毕。
我们目前的方案是:在User中只存储user相关信息,在shop中存储uid(user id)信息,在category中存储sid(shop id)信息,在product中存储cid(category id)信息。这样用户登录之后首先获取uid,然后根据uid扫表获取sid信息,想获取category信息就再根据sid扫表获取所有cid,想查看某cid下的product信息就再扫表获取所有符合cid条件的product文档。
请问这样设计是否合理?有何优劣?请各位探讨一下。
关系数据库也好,NoSQL也好,Schema设计的关键还是要结合业务的访问模型,读写比,数据集大小等,将业务上一起访问的数据放在一起,尤其是读取,并且考虑数据的缓存的设计。
mongodb嵌套有两种模式,parent和child,习惯于采用parent模式,好处是不会导致parent表过度膨胀,缺点是如果child集合的规模过大,反向查询的开销会比较高。
没有完美的设计,只要能够支持业务规模按预期增长2年,有充足的时间进行重构就是好的设计。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。