开发者社区> 问答> 正文

关于MongoDB方案的可行性鉴定

服务器数据库模型是先有一个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文档。

请问这样设计是否合理?有何优劣?请各位探讨一下。

展开
收起
落地花开啦 2016-02-20 17:44:05 2487 0
1 条回答
写回答
取消 提交回答
  • 喜欢技术,喜欢努力的人

    关系数据库也好,NoSQL也好,Schema设计的关键还是要结合业务的访问模型,读写比,数据集大小等,将业务上一起访问的数据放在一起,尤其是读取,并且考虑数据的缓存的设计。
    mongodb嵌套有两种模式,parent和child,习惯于采用parent模式,好处是不会导致parent表过度膨胀,缺点是如果child集合的规模过大,反向查询的开销会比较高。
    没有完美的设计,只要能够支持业务规模按预期增长2年,有充足的时间进行重构就是好的设计。

    2019-07-17 18:45:34
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
Data as a Service - 数据即服务 -- MongoDB⾼级应⽤模式 立即下载
MongoDB多数据中心的方案选型之路 立即下载
饿了么高级架构师陈东明:MongoDB是如何逐步提高可靠性的 立即下载