关于MongoDB应用方案的可行性鉴定

尼再采 发布于 2013/11/05 11:24
阅读 1K+
收藏 0

    本人安卓老手,服务器方面略懂而已,最近在关于服务器的mongodb数据库存储设计方案上有点儿纠结,不知道该怎样抉择,麻烦各位懂行的哥们儿给点儿建议,帮忙指点指点,小弟在这里先谢过了:D

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

    以下是我的疑问,请问这样设计是否合理?有何优劣?也可以不用按照我们现有的思路来,直接给出一个您觉得合理的设计方案。欢迎讨论,并再次感谢!


加载中
0
Joiningss
Joiningss

看来看去,这不是典型的关系型数据库的设计思路吗?没有体现MongoDB文档型数据库的特点

0
尼再采

引用来自“Joiningss”的答案

看来看去,这不是典型的关系型数据库的设计思路吗?没有体现MongoDB文档型数据库的特点

糊涂了,要不然怎么设计呢?怎样才能体现Mongodb文档型数据库的特点呢?还请您不吝赐教,多谢了。。。
0
koolay
koolay
它的显著特点是可以嵌入文档,我觉得shop数据是历史的信息,它不会被修改。因此,shop文档里可以包含更详细的信息,产品,分类 ,可以说是历史的快照
0
尼再采

引用来自“koolay”的答案

它的显著特点是可以嵌入文档,我觉得shop数据是历史的信息,它不会被修改。因此,shop文档里可以包含更详细的信息,产品,分类 ,可以说是历史的快照
所有user,shop,category,product都是可以被修改的。另外,因为处于项目早期,很多业务尚未确定,因此数据还必须保持低耦合的状态。产品没定型,数据结构怎么能够预先定型呢?您说呢?
0
mingkaidox
mingkaidox

引用来自“尼再采”的答案

引用来自“koolay”的答案

它的显著特点是可以嵌入文档,我觉得shop数据是历史的信息,它不会被修改。因此,shop文档里可以包含更详细的信息,产品,分类 ,可以说是历史的快照
所有user,shop,category,product都是可以被修改的。另外,因为处于项目早期,很多业务尚未确定,因此数据还必须保持低耦合的状态。产品没定型,数据结构怎么能够预先定型呢?您说呢?

我觉得,有些数据是可以嵌套的吧,比如每个shop的category可以跟那个shop的信息放一起。
{ shop_id : xxx, categories: { {category_id: c1, ...}, {category_id: c2} ... } }

不过具体还要看需求吧。需求这东西最好早点搞出来(虽然以后也是要改的),要不然代码改来改去是小事,数据库的设计改来改去就困难了。

0
xingren23
xingren23

关系数据库也好,NoSQL也好,Schema设计的关键还是要结合业务的访问模型,读写比,数据集大小等,将业务上一起访问的数据放在一起,尤其是读取,并且考虑数据的缓存的设计。

mongodb嵌套有两种模式,parent和child,习惯于采用parent模式(也就是作者的模式),好处是不会导致parent表过度膨胀(过度膨胀会影响到mongodb的reallocate),缺点是如果child集合的规模过大,反向查询的开销会比较高(虽然可以建索引)。

没有完美的设计,只要能够支持业务规模按预期增长2年,有充足的时间进行重构就是好的设计。

返回顶部
顶部