首页 / MONGODB / MongoDB 一对多关系建模
MongoDB 一对多关系建模
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了MongoDB 一对多关系建模，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4155字，纯文字阅读大概需要6分钟。
内容图文
本篇博客翻译自：
http://blog.mongodb.org/post/87200945828/6-rules-of-thumb-for-mongodb-schema-design-part-1?mkt_tok=3RkMMJWWfF9wsRonsq7Ldu%2FhmjTEU5z14uUsUKGxhokz2EFye%2BLIHETpodcMTcVnM7zYDBceEJhqyQJxPr3FLdcN0tJuRhTrCw%3D%3D
备注：本译文不是严格意义上的翻译，仅仅是在基于对该原文的理解之上，尽可能表达清楚。如有疑问或不妥，请參考原文。
非常多刚从传统SQL开发转向MongoDB开发的朋友都会问到一个问题：怎样用MongoDB表达传统关系数据库中的一对多（1 to n）关系？
基于MongoDB丰富的表达力，我们不能说我们必须採用一个标准的方法来进行1 to n的建模。
稍后我们从3个详细场景来展开解说。
首先。我们将1 to n中的n进行场景细化。这个n到底代表多大的量级呢？是几个到几十个？还是几个到几千个？还是成千上万个？
1） 1 to n（n代表好几个。或几十个，反正不太多）
比方每一个Person会有多个Address。此种情况下，我们採用最简单的嵌入式文档来建模。
{ name: ‘Kate Monster‘, id: ‘123-456-7890‘, addresses : [ { street: ‘123 Sesame St‘, city: ‘Anytown‘, cc: ‘USA‘ }, { street: ‘123 Avenue Q‘, city: ‘New York‘, cc: ‘USA‘ } ]}
这样的建模的方式包括了显而易见的长处和缺点：
长处：你不须要运行单独的查询就能够获得某个Person的全部Address信息。
缺点：你无法像操作独立文档那样来操作Address信息。
你必须首先操作（比方查询）Person文档后，才有可能继续操作Address。
在本实例中，我们不须要对Address进行独立的操作。且Address信息仅仅有在关联到某一个详细Person后才有意义。所以结论是：採用这样的embedded（嵌入式）建模是很适合Person-Address场景的。
2）1 to n（n代表好些个，比方几十个。甚至几百个）
比方产品（Product）和零部件（part），每一个产品会有非常多个零部件。这样的场景下，我们能够採用引用方式来建模，例如以下：
零部件（Part）：{ _id : ObjectID(‘AAAA‘), partno : ‘123-aff-456‘, name : ‘#4 grommet‘, qty: 94, cost: 0.94, price: 3.99}
产品（Product）：{ name : ‘left-handed smoke shifter‘, manufacturer : ‘Acme Corp‘, catalog_number: 1234, parts : [ // array of references to Part documents ObjectID(‘AAAA‘), // reference to the #4 grommet above ObjectID(‘F17C‘), // reference to a different Part ObjectID(‘D2AA‘), // etc ]}
首先每一个part作为单独的文档存在。每一个产品中包括一个数组类型字段（parts），这个数组中存放的是全部该产品包括的零部件的编号（_id主键）。当你须要依据某一个产品编号查询该产品包括的全部部件信息时。你能够运行下面操作：
> product = db.products.findOne({catalog_number: 1234}); // Fetch all the Parts that are linked to this Product> product_parts = db.parts.find({_id: { $in : product.parts } } ).toArray() ;
这样的建模方式的优缺点也很明显：
长处：部件是作为独立文档（document）存在的，你能够对某一部件进行独立的操作。比方查询或更新。
缺点：如上，你必须通过两次查询才干找到某一个产品所属的全部部件信息。
在本例中。这个缺点是能够接受的。本身实现起来也不难。并且，通过这样的建模，你能够轻易的将1 to n扩展到n to n。即一个产品能够包括多个部件，同一时候一个部件也能够被多个产品所引用（即同一部件能够被多个产品使用）。
3）1 to n（这个n代表非常大的数值，比方成千上万。甚至更大）
比方。每个主机（host）会产生非常大数量的日志信息（logmsg）。
在这样的情况下，假设你採用嵌入式建模，则一个host文档会非常庞大，从而轻易超过MongoDB的文档限制大小。所以不可行。假设你採用第二中方式建模，用数组来存放全部logmsg的_id值，这样的方式相同不可行。由于当日志非常多时，即使单单引用objectId也会轻易超过文档限制大小。所以此时，我们採用下面方式：
主机（hosts）：{ _id : ObjectID(‘AAAB‘), name : ‘goofy.example.com‘, ipaddr : ‘127.66.66.66‘} 日志（logmsg）：{ time : ISODate("2014-03-28T09:42:41.382Z"), message : ‘cpu is on fire!‘, host: ObjectID(‘AAAB‘) // Reference to the Host document}
我们在logsmg中，存放对host的_id引用就可以。
综上所述，在对1 to n关系建模时，我们须要考虑：
1）n代表的数量级非常小。且n代表的实体不须要单独操作时，能够採用嵌入式建模。
2）n代表的数量级比較大。或者n代表的实体须要单独进行操作时，採用在1中用Array存放引用的方式建模。
3）n代表的数量级很大时，我们没有选择。仅仅能在n端加入一个引用到1端。
MongoDB 一对多关系建模
标签：person obj res 产生 object mbed sql 朋友 array
本文系统来源：http://www.cnblogs.com/zsychanpin/p/6881257.html
内容总结
以上是互联网集市为您收集整理的MongoDB 一对多关系建模全部内容，希望文章能够帮你解决MongoDB 一对多关系建模所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。