MongoDB数据库设计法则数据库设计法则
Part 1
“我有丰富的sql使用经验,但是我是个MongoDB的初学者。我应该如何在MongoDB中针对一对多关系进行建模?”这是我被问
及最多的问题之一。
我没法简单的给出答案,因为这有很多方案去实现。接下来我会教导你如何针对一对多进行建模。
这个话题有很多内容需要讨论,我会用三个部分进行说明。在第一部分,我会讨论针对一对多关系建模的三种基础方案。在第
二部分我将会覆盖更多高级内容,包括反范式化和双向引用。在最后一部分,我将会回顾各种选择,并给出做决定时需要考虑
的因素。
很多初学者认为在MongoDB中针对一对多建模唯一的方案就是在父文档中内嵌一个数组子文档,但是这是不准确的。因为你
可以在MongoDB内嵌一个文档不代表你就必须这么做。
当你设计一个MongoDB数据库结构,你需要先问自己一个在使用关系型数据库时不会考虑的问题:这个关系中集合的大小是
什么样的规模?你需要意识到一对很少,一对许多,一对非常多,这些细微的区别。不同的情况下你的建模也将不同。
Basics: Modeling One-to-Few : 一对很少
针对个人需要保存多个地址进行建模的场景下使用内嵌文档是很合适,可以在person文档中嵌入addresses数组文档:
这种设计具有内嵌文档设计中所有的优缺点。最主要的优点就是不需要单独执行一条语句去获取内嵌的内容。最主要的缺点是
你无法把这些内嵌文档当做单独的实体去访问。
例如,如果你是在对一个任务跟踪系统进行建模,每个用户将会被分配若干个任务。内嵌这些任务到用户文档在遇到“查询昨
天所有的任务”这样的问题时将会非常困难。我会在下一篇文章针对这个用例提供一些适当的设计。
Basics: One-to-Many:一对许多
以产品零件订货系统为例。每个商品有数百个可替换的零件,但是不会超过数千个。这个用例很适合使用间接引用---将零件的
objectid作为数组存放在商品文档中(在这个例子中的ObjectID我使用更加易读的2字节,现实世界中他们可能是由12个字节组
成的)。
每个零件都将有他们自己的文档对象
每个产品的文档对象中parts数组中将会存放多个零件的ObjectID :