MongoDB 3: 使用中的问题，及其应用场景

导读：用MongoDB去存储非关系型的数据，是一个比较正确的选择。但是，如果只是用MongoDB，那么也会出现一些问题。MongoDB，尤其使用的最佳场景，更多的时候，需要结合关系型数据库共同解决问题。本篇博客，则介绍一下MongoDb在运用过程中可能出现的问题。

 

一、出现的问题

首先，我们先来简单看一下MongoDB的存储结构图(以电视节目为例)：

那么以传统的关系型数据库存储，这将要建立好几张表，但如果用非关系型，则是：

 

<span style="font-family:KaiTi_GB2312;font-size:18px;">{title:'Angel's Class',
 seasons:[
	{
		season_number:'1',
		episodes:[
			{
				ordinal_within_season:'1',
				title:'what is it',
				reviews:[{...}],
				cast_members:[{...}]
			}
		]
	}
 ]
}
</span>

通过jsonArray的，只存储一个对象，就可以获得想要的数据。可是，问题也因此而来（以facebook的使用为例）：

 

那么，以上的结构，如果以关系型数据库作为存储，当我们需要获取数据时，则需要联合查询好几张表。那么这时候，为了简便，以非关系型数据库作为存储的概念出来了，如下所示：

这时候，我们依然能通过存储一个对象，获取我们想要的数据。可是，当我们试图去更新着一条记录的时候，那么这将是项危险的操作，我们不得不去更改这个对象里涉及到的所有数据（也许只是想改个自己昵称而已）。（它的危险来源于：信息嵌套）

这个时候，或许我们需要引入id：

这时候，我们仍然可以通过一个文档去获取用户的完整数据，但对于里面涉及到的User2等数据，则需要在程序中去编写代码！

 

二、结合项目的思考

在最近做的今日开讲的项目中，那么作为讲师模块，一个添加或者编辑，需要操作5张表：Student，Teacher，UserFied，UserIndustry，WorkExperience，其中用户领域和行业、工作经验都可以是多个。那么我们用MySQL的时候，则每次都需要查4次，一次：联合Student和Teacher表，去获得用户的基本信息。其余的是，分别查询讲师的领域、行业和工作经验。

那么，在这个需求中，并不涉及到信息的嵌套和危险操作。如果使用Mongo的话，那么一个讲师只需要查询一个对象就可以获取出所有的数据。这样，在编程的时候，我们就可以更多的，以系统的业务逻辑实现去思考问题，而可以将数据的持久化操作暂时搁浅。

PS：后来想过了，这个系统在很多地方还是得用关系型的数据库（在非关系的数据库里，尽可能的不要去link你的document）。那么即使使用Mongo可以在一定程序一定范围内方便，但是对于整个的学习成本、时间成本、维护成本考虑，结合系统的规模来说，或许不是一个最佳的选择！

 

三、总结

在什么时候使用MySQL之类的数据库呢？当我们需要进行复杂的、多行的数据交易；高度事务性的系统。

在什么时候使用Mongo之类的数据库呢？个人观点：可以将Mongo（高性能）作为一个缓存用，避免下层数据的过载；作为视图（作为全局来看，Mongo的文档存储，其实很像关系型数据库中的视图 ）；存储Json对象，实时性的数据。

总结：在选择数据库的时候，很重要的一件事就是：明确业务需求，数据类型，让数据库（数据）为业务服务！

分享：在计算机科学中，最艰难的有两件事：缓存失效和命名！