我来自SQL世界,所以很自然mongo / noSQL一直是冒险。
我正在构建一个页面来添加/编辑类别,"发布"稍后将被分配到。
我基本上创造的是:
{
_id: "asdf234ljsf",
title: "CategoryOne",
sortorder: 1,
active: true,
children: [
{
title: ChildOne,
sortorder: 1,
active: true
},
{
title: ChildTwo,
sortorder: 2,
active: true
}
]
}
所以稍后,当创建"帖子"我会将该帖子分配给一个或多个父类别,以及可选择的父类别中的一个或多个子类别。访问该网站的访问者如果点击了父类别,则会显示该父类别中的所有帖子,如果他们选择了子类别,则只显示该子类别中的帖子。
逻辑显而易见,但在SQL中我会创建这样的表:
table_Category ( CategoryID, Title, Sort, Active )
table_Category_Children ( ChildID, ParentID, Title, Sort, Active )
我一直在阅读Discover Meteor一书,它提到Meteor为我们提供了许多工具,这些工具在收集级别操作时效果更好,以及DDP如何在文档的顶层操作,意味着如果子集合或数组中的某些小变化,可能不需要的数据将被发送回所有连接/订阅的客户端。
所以,这让我觉得我应该像这样组织类别:
Collection for parent categories
{
_id: "someid",
title: "CategoryOne"
sortorder: 1,
active: true
},
{
_id: "someid",
title: "CategoryTwo"
sortorder: 1,
active: true
}
Collection for Child Categories
{
_id: "someid",
parent: "idofparent"
title: "ChildOne"
sortorder: 1,
active: true
},
{
_id: "someid",
parent: "idofparent"
title: "ChildTwo"
sortorder: 1,
active: true
}
或者,或许这样更好:
Collection for parent categories
{
_id: "someid",
title: "CategoryOne"
sortorder: 1,
active: true,
children: [ { id: "childid" }, ... ]
}
我认为在这种情况下了解Meteor和Mongo的最佳实践/方法将对我有所帮助。
结论:我有一个管理页面,我在其中添加/编辑这些类别。当客户创建帖子时,他们会选择适合其帖子的父类别和子类别,并确保我从一开始就正确组织它。将我的思维过程从传统的RDBMS改为NoSQL是一个很大的进步。
谢谢!
答案 0 :(得分:0)
MongoDB将所有数据存储在文档中。这是与SQL之类的关系数据库的根本区别。
想象一下,如果您有100个父类别和1000个子类别,一旦更新父类别,它将以被动方式影响所有链接的子类别" idofparent"简而言之,它不可持续。
尝试在MongoDB中考虑避免JOIN SQL等效的方法。 重构您的数据可能与此类似:
所有类别的一大集合:
{
_id: id,
title: title,
sortorder: 1,
active: 1,
class: "parent > child" // make this as a field
...
}
// class can be "parent1", "parent2", "parent1 > child1" ... you get the idea
因此每个文档存储都是完全独立的。 或者,如果您绝对需要JOIN关系数据结构,我不认为MongoDB是您的正确选择。