比如下面这种学生选课的模型,既要知道学生选了哪些课,又要知道课被哪些学生选了。传统的 SQL 就是下面这写法了,如果换成 key-value 的,该怎么描述呢?
Student: Id Name Course: Id Name Relation: Student_Id Course_Id
闭关修行中......
可以这样设计,collection里面每个文档存储一个学生的选课数据:
// students { _id: ObjectId('4e7020cb7cac81af7136236b'), name: "...", choose_lesson: [ {_id:ObjectId('4e7020cb7cac81af71362361'), lesson_name: "..." }, {_id:ObjectId('4e7020cb7cac81af71362362'), lesson_name: "..." } ] }
学生选了哪些课?
db.students.find( {_id: ObjectId('4e7020cb7cac81af7136236b')}, {choose_lesson: 1} )
一门课有哪些学生选择?
db.students.find( {choose_lesson: {$elemMatch: {lesson_name: "..."}}}, {name: 1} )
参考了mongodb 用户点赞功能怎么设计比较合理?
在这个业务上,我觉得是一样的。
在Relation中直接保存Student的Id和Course的Id,或者用DBRefs。个人觉得前者就行。 可参考:http://docs.mongodb.org/manual/reference/database-references/。
可以这样设计,collection里面每个文档存储一个学生的选课数据:
学生选了哪些课?
一门课有哪些学生选择?
参考了mongodb 用户点赞功能怎么设计比较合理?
在这个业务上,我觉得是一样的。
在Relation中直接保存Student的Id和Course的Id,或者用DBRefs。个人觉得前者就行。 可参考:http://docs.mongodb.org/manual/reference/database-references/。