首页>软件资讯>常见问题

常见问题

MongoDB教程熟练到精通(二): JSON 文档模型设计的常见误区及其与关系模型的区别

发布时间:2023-01-12 09:50:59人气:159

上一篇中,我们已经初步掌握了模型设计的基础以及关系模型的建模过程,本篇重点为:JSON 文档模型的设计。


MongoDB 文档模型设计的常见误区


MongoDB 是 Schemaless,不需要模型设计(❌)

MongoDB 设计模式非常简单,就是用一个超级大文档来组织所有数据,一张表即可搞定(❌)


MongoDB 是 NoSQL 不支持关联或者事务,因此只能用在较为边缘化的小场景上(❌)

以上是三个关于 MongoDB 文档模型设计的常见误区,那么正确的 MongoDB 模型设计应该是怎么样的,这种误解又是如何产生的?


① 关于 MongoDB 是否需要建模

1.png

上一篇有提到,传统建模过程通畅包括三个步骤,从概念建模到逻辑建模到物理建模。在关系模型设计中,真正的关系模型设计就处于第三层物理建模。同样的,在 JSON 文档模型设计中,文档模型设计也属于第三层。虽然前两步也都是必要的,但在实际工作中,其实很少会真正依循这个步骤来执行,往往都是直接跳到第三步物理建模。但非常不同的是,关系模型在物理建模时需要明确画出 ERD 图,把表和主外键定义出来,然而文档模型只需要定义出 JSON 文档,不遵从第三范式,允许冗余,不需要用主外键关联,而是通过内嵌数组或引用字段来表示关系。


② 为什么都说 MongoDB 是无模式?

2.png


对于文档模型而言,由于其自身的 JSON 特色,建模时的物理模型和逻辑模型中的对象模型其实非常接近。简言之,JSON 文档模型设计的物理层架构可以和逻辑模层类似。因此从某种程度来看,我们可以跳过物理模型建模,仅用逻辑模型就可以完成类似的文档模型建模过程。那么假如我们最初就没有从概念模型开始,物理建模的具体过程又可以省略,就显得 MongoDB 好像完全是无模式的,这便是 Schemaless 误区的由来。但事实上,严格来说, MongoDB 和关系型数据库一样,同样需要概念建模和逻辑建模这两个必不可少的步骤。模型设计对于 MongoDB 而言,同样非常重要。


附逻辑模型与 JSON 模型的举例对比:

3.png

如上图所示,仍然以联系人管理为例,假设现有联系人一位,并列出姓名、性别、电话、分组、地址等信息,这样一个物理逻辑模型在关系模型里可能需要分成多张表,但在 JSON 模型里,则可用一个表或一个集合把这些信息,以及其间一对多、多对多等关系都表现出来。所以某种意义上来说,当我们完成逻辑建模时,也就完成了几乎大半的文档模型建模工作,也就是前面所说的“省略了最后一步”。

文档模型的设计原则


然而对于文档模型设计而言,不受第三范式原则约束,既有好处,也存在弊端,那就是会导致我们很难明确按照什么样的法则来建模,以及如何判断模型的好坏。


谈及文档模型的设计原则,主要有以下两个关键点:


性能(Performance):能否支撑得非常高并发、低延迟的读写。

开发易用(Ease of Development):设计出的模型在程序中开发时是否容易使用

当然,不同于第三范式这样明确的科学规则,这两点原则更偏向经验之谈,很难直接遵循采用。因此在后续的文章中,我们会从多个方面切入,为大家设计文档模型提供一些更加明确的思路。

小结:关系模型与文档模型的差异

4.png


首先从模型设计的层次来看,严格意义上,关系数据库的建模包含从概念到逻辑到物理三层;JSON 文档模型下,物理模型则变为可选项,如果和逻辑模型一致,则可跳过。


从模型实体来看,关系数据库用表来表示模型实体,而 MongoDB 则用集合表示。


从模型属性来看,关系模型中相对简单,是列来实现, 而 JSON 文档通常有用字段方式。


最后也是最大的不同点在模型关系方面,关系数据库建模通常通过主外键、关联关系来表示;而 JSON 文档模型大多使用内嵌数组的方式来表示,偶尔也会用到引用字段。


本篇主要主要介绍了 JSON 文档模型的设计的原则及其和关系模型设计的一些区别点。在此基础上,下一篇开始,我们会给大家介绍有关文档模型构建的具体方法论。



上一条:MongoDB教程熟练到精通(一):模型设计基础知识详解

下一条:Chemdraw哪个好用