前言:原文地址 https://www.cnblogs.com/zsychanpin/p/6881257.html
MongoDB 一对多关系建模
本篇博客翻译自:
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。此种情况下,我们採用最简单的嵌入式文档来建模。
长处:你不须要运行单独的查询就能够获得某个Person的全部Address信息。
缺点:你无法像操作独立文档那样来操作Address信息。
你必须首先操作(比方查询)Person文档后,才有可能继续操作Address。
在本实例中,我们不须要对Address进行独立的操作。且Address信息仅仅有在关联到某一个详细Person后才有意义。所以结论是:採用这样的embedded(嵌入式)建模是很适合Person-Address场景的。
2)1 to n(n代表好些个,比方几十个。甚至几百个)
比方产品(Product)和零部件(part),每一个产品会有非常多个零部件。这样的场景下,我们能够採用引用方式来建模,例如以下:
首先每一个part作为单独的文档存在。每一个产品中包括一个数组类型字段(parts),这个数组中存放的是全部该产品包括的零部件的编号(_id主键)。当你须要依据某一个产品编号查询该产品包括的全部部件信息时。你能够运行下面操作:
长处:部件是作为独立文档(document)存在的,你能够对某一部件进行独立的操作。比方查询或更新。
缺点:如上,你必须通过两次查询才干找到某一个产品所属的全部部件信息。
在本例中。这个缺点是能够接受的。本身实现起来也不难。并且,通过这样的建模,你能够轻易的将1 to n扩展到n to n。即一个产品能够包括多个部件,同一时候一个部件也能够被多个产品所引用(即同一部件能够被多个产品使用)。
3)1 to n(这个n代表非常大的数值,比方成千上万。甚至更大)
比方。每个主机(host)会产生非常大数量的日志信息(logmsg)。
在这样的情况下,假设你採用嵌入式建模,则一个host文档会非常庞大,从而轻易超过MongoDB的文档限制大小。所以不可行。假设你採用第二中方式建模,用数组来存放全部logmsg的_id值,这样的方式相同不可行。由于当日志非常多时,即使单单引用objectId也会轻易超过文档限制大小。所以此时,我们採用下面方式:
综上所述,在对1 to n关系建模时,我们须要考虑:
1)n代表的数量级非常小。且n代表的实体不须要单独操作时,能够採用嵌入式建模。
2)n代表的数量级比較大。或者n代表的实体须要单独进行操作时,採用在1中用Array存放引用的方式建模。
3)n代表的数量级很大时,我们没有选择。仅仅能在n端加入一个引用到1端。