MongoDB嵌套设计理念
我正在创建一个系统，其中一家公司有多个用户、客户等。我不能决定是否创建“对象”，例如用户、公司文档的单独集合或嵌入文档。
Company (Object) ->
Users (Object) ->
Profile (Object) ->
...attrs..
History (Object) ->
...attrs...
Customers ->
...attrs...我现在被困在关系数据库的思维模式中，不确定用NoSQL做这件事的“适当”方式。你的想法是什么？
当一个双重嵌入的文档(如公司>用户->历史)变得非常大时会发生什么？
嵌入式文档方法(如果有的话)还有哪些其他缺点？再一次，我偏向于关系思维模式。
提前谢谢。
回答 3
Stack Overflow用户
发布于 2012-04-20 10:56:52
http://www.mongodb.org/display/DOCS/Schema+Design有一些关于模式设计的建议，还有10Gen成员的各种演示文稿，比如：http://dl.dropbox.com/u/205597/sts/sts-04-2012-mongo-and-nosql-schema.pdf
考虑到公司中可能的用户数量和历史对象的可能数量，我认为您可能需要为每个对象单独收集一个集合。
Stack Overflow用户
发布于 2012-03-12 19:07:01
我可以在这里给出一些一般性的建议，但最终将由您决定采用哪种方法。要确定是嵌入还是引用，您需要问的问题是：
在获取大多数查询的文档时，需要返回哪些数据？
这可能很简单，也可能很复杂--如果99%的查询都会返回相同的5个字段，那么答案是显而易见的。如果你很少需要一段数据，那么它是一个单独收集的候选者。您需要第二次查找来获取该数据，并在它们之间进行某种类型的引用，但是这种稀缺性使得这种开销是可以接受的。
当然，如果您的数据集和返回值不是那么清晰，那么它就变成了一个更复杂的问题。
如果经常需要某个字段，但不是所有字段都需要(比如历史记录中的最后5个条目)，则将它们以固定大小存储在主文档中，并将其余字段存储在单独的集合中。这会导致一些重复并使您的更新复杂化，但在速度方面可能是一个很好的权衡。
就缺点而言-一个大的嵌入式文档本身并不坏，但是一个不断增长的文档，特别是一个无限增长的文档可能是不好的。每次文档增长时，都有可能它对于分配的空间来说太大，这意味着它将不得不移动。这不仅会将您的数据分成碎片，而且对于移动大型文档、分配新空间来说，这可能是一项代价高昂的操作--特别是如果您经常这样做的话。填充因子文档很好地解释了这一点(触发移动时会添加填充因子)：
http://www.mongodb.org/display/DOCS/Padding+Factor#PaddingFactor-Overview
希望它能帮上忙！
Stack Overflow用户
发布于 2012-04-20 10:43:38
如果你不需要自己查询和获取相关数据的统计数据等，那么将其嵌入，这也会加快查询速度。如果您出于某种目的需要提取此数据，请为其创建新的集合。
https://stackoverflow.com/questions/9650407
复制相似问题
腾讯云开发者
