需求是用户下单购买课程,对象有用户、订单、课程,是多对多关系。 关系型数据库中创建三张表即可,订单表中有UserId, CourseId。
请教MongoDb中如何设计多对多关系?也是创建三个Schema吗?
表示不会,只是mark
是要创建三个Schema 相互用ref指引就好了
这种多对多的关系就不应该使用mongodb。 先弄清楚mongodb是用来干嘛的。 一方面mongodb自己想引导别人使用mongodb. 另一方面由于ssd的出现mongodb的性能优势也不明显了。
mongodb不是关系型数据库。 如果是这样, 就没必要使用mongodb
实在没办法就类似关系数据库范式一样,搞个关联集合,不过觉得好怕怕
确实,noSQL不能走老路,我觉得是看数据量的。一般来说,用户很多,订单很多,课程不多。所以用户一个表,订单一个表,用户里有订单ID和课程的数组,订单里有用户ID和课程数组。也方便一次查询就能出所有的数据,不用多次查询。
@klausgao 如果我要单独维护课程信息,是不是用嵌套的方式就不行了。
我还想要知道,既然用了nosql了,那什么情况下用嵌套比较好,什么情况下还是会用ref做关联? 以及嵌套和引用在最终使用上有什么差别,是不是嵌套适合于要求性能,查询,引用适合于对象经常更新或者需要单独维护?
例如,我知道这种情况下,文章Post对象,可以有标签Tag,这种场景,就可以Post里面直接用[]包含tag数组。
@icmr 个人觉得,空间换时间。也就是如果要一次性查询就能出来的,不是都是动态数据的,就尽量放在同一个集合里。 你有单独的一个课程信息collection是OK的, 例如有一个页面(查询),显示的是某人的所有按日期的课程信息,可以认为课程信息是固定的(老师、科目、内容简介、时长什么的)。那我建议就同时在用户的Object里有个Array,放上该用户的课程安排,就能一次性查询出来了。如果课程有变,你在后台可以有操作去更新这些内容。 其实你想想微博微信推特这些类型的数据结构,就是这样的,要么是push要么是pull,就看哪个的代价更小。