我是MongoDB的新手，所以请耐心等待。
我有两个问题：
首先，请采取以下措施：
// add a record
$obj = array( "title" => "Calvin and Hobbes", "author" => "Bill Watterson" );
MongoDB是否将“title”和“author”存储为此集合中此对象的每个条目的文本？或者它是否创建了一个模式并将它们转换为字段数字（或者根本没有存储并纯粹存储数据）？
我的第二个问题是：什么时候应该使用“关系”？假设我有100个经销商，每个经销商包含（对象）1,000个客户，每个客户有10个项目。这使得一个巨大的整体对象可以操纵。
在SQL世界中，这都将与“对象”相关。在Document world中，我们尝试通过嵌入子对象来存储完整的对象。
然而，这可能是笨拙的。这是什么最好的做法？有人可以指点我的指南。
感谢。
答案 0 :(得分：13)
此集合中每个条目的MongoDB字段名称是什么？
是的，MongoDB确实存储了每条记录的文本。实际上，如果磁盘空间是一个限制因素，这通常不是太大的问题，您可能需要考虑其他因素。
什么时候应该使用“关系”？
这更像是一门艺术，一门科学。 Mongo Documentation on Schemas是一个很好的参考，但有些事情需要考虑：
尽可能多地放入
文档数据库的乐趣在于它消除了大量的连接。你的第一直觉应该是尽可能多地放在一个文件中。因为MongoDB文档具有结构，并且因为您可以在该结构中有效地进行查询，所以不需要像在SQL中那样对数据进行规范化。特别是除了父文档之外没有用的任何数据都应该是同一文档的一部分。
可以从多个地方引用到自己的集合中的分隔数据。
这不是一个“存储空间”问题，因为它是一个“数据一致性”问题。如果许多记录将引用相同的数据，则更高效且更不容易更新单个记录并在其他地方保留对它的引用。
文档大小注意事项
MongoDB对单个文档施加了4MB的大小限制。在GB数据世界中，这听起来很小，但它也有3000万条推文或25万条典型的Stack Overflow答案或20张闪烁照片。另一方面，这是一个人可能希望在典型网页上同时呈现的信息。首先考虑什么会使您的查询更容易。在许多情况下，对文档大小的关注将是过早优化。
在您给出的示例中，我将制作3个单独的集合，因为我不需要知道为项目创建列表的其他9个项目。我会保持简单的查询。 （但请参阅底部的Protip）
复杂的数据结构：
MongoDB可以存储任意深层嵌套数据结构，但不能有效地搜索它们。如果您的数据形成树，林或图形，则实际上需要将每个节点及其边缘存储在单独的文档中。 （请注意，还有专门为这类数据设计的数据存储，也应该考虑）
数据一致性
MongoDB在效率和一致性之间进行权衡。规则是对单个文档的更改始终原子，而对多个文档的更新永远不应该被假定为原子。也无法“锁定”服务器上的记录（您可以使用例如“锁定”字段将其构建到客户端的逻辑中）。在设计模式时，请考虑如何保持数据的一致性。通常，您在文档中保留的越多越好。
专业提示
即使您使用引用，通常最好在父文档中保留引用中的一些数据。一般来说，我保留足够的信息来建立一个有意义的链接到父母的后代。
在您的示例中，这将意味着将客户端名称与转销商文档中的ObjectID一起保留，以便我可以按名称创建指向每个客户端的链接，而无需单独的查询。如果构建客户端的URL需要除了文档ID之外的其他东西，我也会存储它。
这样的技巧可以减少1 + n查询情况。
答案 1 :(得分：1)
MongoDB是否存储“标题”和 “作者”作为每个单词的文本 在此输入此对象 集合？
MongoDB是无模式的 - 所以答案是显而易见的：是的，因为没有架构这样的东西
我的第二个问题是：什么时候应该 “关系”被使用？让我说我有 100个经销商，包含 （逐个对象）每个1,000个客户，和 每个客户有10个项目。那 使一个巨大的整体对象 操纵。
请检查
http://www.mongodb.org/display/DOCS/Schema+Design
您的选项包括嵌入式文档，数据库引用或多个查询。