我的目标是设计一个可扩展的递归树数据模型,该模型与垂直大小、水平大小、树不平衡和总体大小无关。
在 Mongo 的网站上,他们在这里讨论树结构数据:
http://docs.mongodb.org/manual/applications/data-models-tree-structures/
有趣的是,他们提供的每个数据模型都表示集合中的一个新条目;即使对于子元素
让我们从 mongodb.org 示例 A 中调用以下内容:
db.categories.insert( { _id: "MongoDB", parent: "Databases" } )
db.categories.insert( { _id: "dbm", parent: "Databases" } )
db.categories.insert( { _id: "Databases", parent: "Programming" } )
db.categories.insert( { _id: "Languages", parent: "Programming" } )
db.categories.insert( { _id: "Programming", parent: "Books" } )
db.categories.insert( { _id: "Books", parent: null } )
现在,我们将此称为示例 B:
singleEntry =
{
_id: "Books",
children:
[
{
_id: "Programming",
parent: "Books",
children:
[
{
_id: "Languages",
parent: "Programming"
},
{
_id: "Databases",
parent: "Programming",
children:
[
{
_id: "MongoDB",
parent: "Databases"
},
{
_id: "dbm",
parent: "Databases"
}
]
}
]
}
]
}
db.categories.insert(singleEntry)
我真的很喜欢示例 B;尽管双重引用父子关系是令人不安的多余,但我找不到在实际使用中避免这种情况的方法。此外,查询也更加复杂:
db.categories.find(
{
'children.children.children._id' : 'MongoDB'
}
)
但我不介意,只要示例 A 中的所有内容都可以在示例 B 中实现。
我感觉可能不是。我担心的其他问题是:
- 最大条目大小
- 最大堆栈大小
- 插入高度嵌套的集合条目会对重新排列内存中内容的引擎造成严重破坏
我对 Mongodb 的最初理解是它是为了这样的模式设计而设计的。然而,当我查看文档、示例,甚至 shell 方法时,看起来他们确实希望它像示例 A 一样。
示例 A 的某些内容似乎过于相关;这就是我试图摆脱的。如果我采用示例 A,为什么不直接使用 SQL?如果我采用示例 B,我会遇到什么情况?
最佳答案
您将遇到的一个问题是 document size limit of 16MB 。对于样本 B 中的方法来说,这绝对是一个 killer ,除了非常小的数据库。
NoSQL 和 MongoDB 数据建模的工作方式与 SQL 数据库的数据建模有着根本的不同。下面的内容有点简化,但您已经明白了。
使用 SQL 数据库,您可以根据实体对数据进行建模并确定它们之间的关系。在下一步中,您尝试确定如何回答用例中出现的问题。
在 MongoDB 数据建模中,您首先要确定用例中出现的问题,然后对数据进行相应的建模,以最有效的方式回答您的问题。
此外,在某些用例中,NoSQL 数据库(特别是 MongoDB)并不理想。然而,在 SQL 数据库中建模树结构通常也是一件令人头疼的事情。使用像 Neo4J 这样的树数据库可能更适合重结构树。然而,几乎可以使用任何数据库来构建商店系统或某物的类别结构。我会根据项目的几乎所有其他功能和非功能需求来选择数据库。
关于mongodb - Mongo树数据模型设计,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29610180/