MongoDB的数据建模

MongoDB是一种面向Document的NoSQL数据库,如果我们还是按照RDB的方式来思考MongoDB的数据建模,则不能有效地利用MongoDB的优势;然而,我们也不能因为Document的灵活性,就可以在设计之初放任自流。

适度的建模是非常有必要的,尤其对于相对复杂的关联关系。因为在MongoDB中,处理这种关联关系既可以使用Link,也可以使用Embedded。

我们要评价一种决策,不能将其与具体的上下文割裂开来做判断,那种单纯说A技术要比B技术好的做法,就像小孩子看卡通片里的人物只知道说谁是好人谁是坏人一般的幼稚。世界上没有一种完美至善的技术,关键还是要结合场景来看使用是否得法。

例如使用Embedded方式,就各有优缺点。举例来说,倘若我们采用Embedded方式将Addresses作为Person对象内部的数组:

{
  name: 'Kate Monster',
  ssn: '123-456-7890',
  addresses : [
     { street: '123 Sesame St', city: 'Anytown', cc: 'USA' },
     { street: '123 Avenue Q', city: 'New York', cc: 'USA' }
  ]
}

当我们在查询Person的信息时,要获取其内嵌的属性细节,我们无需再执行多次查询。倘若我们改变一下领域场景,需要开发一个任务跟踪系统。如果我们将Tasks的信息嵌入到Person对象中,当我们面对以下需求:

  • 显示所有明天到期的任务
  • 显示所有未完成的任务

采用这种Embedded就不那么令人愉快了。

如果采用Link方式,情况就完全不同了:

//Tasks
[
    {
        _id: ObjectID('AAAA'),
        task_number: 1234,
        taks_name: 'Prepare MongoDB environment',
        due_date: '2017-01-15'
    },
    {
        _id: ObjectID('BBBB'),
        task_number: 1235,
        taks_name: 'Import Test Data',
        due_date: '2017-02-15'
    },
]

//Persons
{
  name: 'Kate Monster',
  role: 'Manager',
  tasks : [
    ObjectID('AAAA'),
    ObjectID('BBBB')
  ]
}

有得必有失,当我们需要查询Person承担的Tasks时,采用这种方式,就需要采用application-level join方式执行两次查询。

这种建模方式还带来另一种可能,就是原本Person->Tasks的one-to-N关系就可以变为N-to-N关系,因为一个Task可以被多个Person所拥有。如果采用Embedded方式,则会导致Task数据的冗余。

在文章 6 Rules of Thumb for MongoDB Schema Design中,作者将这种1对N关联实现的判断依据划分为三种形式:

  • one-to-few
  • one-to-many
  • one-to-squillions

但我认为该怎么实现关联,应该从Entity之间的领域关系来判断,我们可以引入DDD的Aggregation设计概念作为建模的依据。简单来说,如果使用Embedded,可以认为该Entity处于Aggregation边界之内,对外应该通过Aggregation Root来访问。文章 6 Rules of Thumb for MongoDB Schema Design的说法就是:

Will the entities on the “N” side of the One-to-N ever need to stand alone?

如果是Stand Alone,就意味着该Entity可以成为一个独立的Aggregation,然后再通过ID与另外一个Aggregate关联。

在SegmentFault上则有人做了如此总结

  • FirstClass (比如“User”这种) 应该用独立的Collection
  • "条目类型"的,应该 embedded
  • 两个模型之间如果是包含关系,用 embedded
  • 多对多关系,用 link(类似sql里面的foregin key)
  • 如果一个模型,其可能存的对象很少,那么就用独立的collection,这样有助于mongodb server做缓存
  • embedded方式不利于做复杂的关联,复杂的查询
  • embedded方式性能很有优势,如果你有“性能”方面的要求,可以考虑用embbed

原文发布于微信公众号 - 逸言(YiYan_OneWord)

原文发表时间:2017-01-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏熊彪的专栏

精准测分:基于函数调用关系链的用例消振算法 ( 上帝视角 )

地球文明不是孤岛,函数呢?从静态的视角观察函数,她只是一个一个在文件中孤立存在的代码片段。但从动态的视角观察,函数与函数之间就天然的发生了关联。这个关联是怎么产...

1930
来自专栏数据结构与算法

洛谷P2439 [SDOI2005]阶梯教室设备利用(带权区间覆盖)

964
来自专栏yw的数据分析

R语言写2048游戏

       2048 是一款益智游戏,只需要用方向键让两两相同的数字碰撞就会诞生一个翻倍的数字,初始数字由 2 或者 4 构成,直到游戏界面全部被填满,游戏结...

5424
来自专栏令仔很忙

UML总结

   描述类与类之间的使用与被使用关系,而其使用关系具有偶然性的、临时性的、非常弱的,但是被使用的一方会影响到使用的一方,比如说:“动物”和“氧气”,动物的生活...

801
来自专栏牛客网

拼多多、网易、华为面经

统共面试了三家公司,本来打算偷懒不打算写面经,不过还是写一下吧,如果能帮到人的应该也算是件好事,具体的事件太久忘了

1601
来自专栏机器之心

资源 | 知网(HowNet)知识库的简单调用指南

机器之心整理 参与:蒋思源 机器之心曾采访过语知科技的董强先生,在那一篇文章中,我们详细讨论了基于知网知识库的 NLP 解决方案。虽然我们已经了解了这种方法的潜...

6045
来自专栏程序人生

谈谈状态机

题记:上周做 BBL 里讲了我们 Tubi TV 内部做 DSL 的一些简单实践,大家反馈不错。有同事建议我给大家先补补 FSM,之后再进阶 CFG,可能会更顺...

3257
来自专栏Aloys的开发之路

OOAD与UML笔记

UML基础介绍 1.UML的定义 统一建模语言(UML)是一种图形化的语言,它可以帮助我们在OOAD过程中标识元素、构建模块、分析过程并可通过文档说明系统中的重...

1908
来自专栏CSDN技术头条

Weiflow:微博也有机器学习框架?

本文从开发效率(易用性)、可扩展性、执行效率三个方面,介绍了微博机器学习框架Weiflow在微博的应用和最佳实践。 在上期《基于Spark的大规模机器学习在微博...

3108
来自专栏架构说

leetcode打家劫舍问题

https://leetcode-cn.com/problems/house-robber/description/

1352

扫码关注云+社区