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。此种情况下,我们采用最简单的嵌入式文档来建模。

 

{
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端。

posted @ 2016-04-19 09:43  iDark  阅读(510)  评论(0编辑  收藏  举报