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