我有一个类似于以下的数据库:
我们有“项目”,项目将由多个“步骤”组成,每个步骤都有多个“待办事项”。
想到的第一个模式是这样的:
{
project_name: "name",
due_date: "some date",
steps: [
{
step_name:"name",
description: "description",
step_category:"category"
todos: [
{
todo_name:"name",
todo_description: "description",
due: "date"
}
]
}
],
}
但是,我希望对“待办事项”和“步骤”进行大量查询。例如,关于单个待办事项的统计信息,或按类别分类的待办事项(这将是步骤的一部分),可能查询范围从项目截止日期到获取待办事项。
那么我的主要问题是“模式”结构的最佳实践是什么。我认为最好的方法是将“项目”、“步骤”和“待办事项”隔离到它们自己的集合中,并为它们的 id 和查询的其他相关数据编制索引。然而,由于 mongodb 并不是真正的关系型数据库,我想知道这种方法是否适用。虽然我不希望“待办事项”在很长一段时间内超过一百万份文件。
注意:我不会使用关系数据库,因为我的原始案例并不是真正的待办事项应用程序。我以此为例。我的“待办事项”是实体,它们具有非常不同的类型,每种类型具有不同的属性,并且可能容易发生变化,这就是我计划使用 mongodb 的原因
在MongoDB:权威指南的第 210 页上,我们对树设计模式进行了描述,这听起来与您在此处遇到的问题类似,其中“当您有大量查询并且具有分层结构的数据时,可以应用此模式。 “ 我进一步深入研究并找到一个包含子引用的树结构,这可能对您在此处尝试执行的操作有益。例如,假设我们有一个如下所示的架构:
看起来像这样: