MongoDB 的饭碗端的越来越牢

部门表

ID 

部门名称

部门曾用名

部门职能

员工表

ID  

姓名

年龄

职位

所述部门ID

职位

睡不着，脑子有时不受你控制的要想些什么东西，而想到了不写出来，很可能就和做梦一样，清醒的时候就忘记了，感谢微信分享的同学。

Warm up, 提到MONGODB ，就不能不说JOSN， MONGODB 的用法中JOSN 对其推波助澜的作用不言而喻。 举个例子，目前的世界语言，是英文（说错了，也别介意，举个例子，我希望那天是中文），在联合国的交流中，基本上都是以英文体现。

而在信息或消息传递，并且是跨平台的交互中，JSON属于这样的语言之一，并且有越发不可收拾的地步，如果程序员不懂JSON 那估计有一半的活都干得不顺手。

在各个程序模块中，消息的传递大多数都是可以考虑使用JSON 来满足消息的传递需求。MONGODB 作为与 JSON 关系最密切的数据库之一（也可以说是NO.1）,饭碗端的牢固也就顺其自然了。

今天不想说 BULA BULA为MONGODB 歌功颂德，倒是想说说，在某些系统设计中，使用MONGODB 的想法。

1  程序快速研发和需求（某些项目）

一个软件项目的开始大部分都是有一个实际的项目需求，而很多项目需求开始本身就是混乱的，不是因为项目不好或管理项目的人有问题，而是时间成本和变化的项目需求之间的矛盾。

举个例子，有些项目本来进行的很好，但在进行中，突然杀出程咬金，最终结果就是程序还的改，数据库的表设计又要修补，甚至推到重来。

面对这样的情况下，传统数据库的弊病就来了，因为需要固化字段，字段的默认值，以及各种约束 等等，这些都是要花时间的。 如果你是一个很紧急的项目，并且未来可能在项目的运行后，还可能有不少变动，传统数据库其实就有点捉襟见肘。

MONGODB的无结构化是尽人皆知的事情，这里举个例子。

公司的员工表，这里需要考虑员工所在的部门，以及人员的变动

如，我们有两个表一个公司的部门表，一个是员工的表

部门表

ID 

部门名称

部门曾用名

部门职能

员工表

ID  

姓名

年龄

职位

所述部门ID

职位

如果查询某个员工的所属部门，大致要这样写

select 姓名，所属部门

from 员工表，部门表

where 员工表.所属部门ID = 部门表ID and 姓名 = ‘XXX’

或者

select 姓名，所属部门

from 部门表

left join 员工表 on 部门表.id = 员工表.部门ID

where 姓名='xxx'

这里问一个奇怪的问题，这个员工很特殊，他属于两个部门， 是的现实世界就有这样的问题，你怎么办。而且就要求你，通过那个部门都能查到这个人。

表设计还的改

部门表

ID 

部门名称

部门曾用名

部门职能

员工表

ID  

姓名

年龄

职位

所述部门ID_1

所属部门ID_2

职位_1

职位_2

好的我又加了两列可以了吧，如果更变态一点，他属于三个部门，你怎么办。这样的极不稳定的状态需求，对于传统的表设计当然是可以有更好得办法，但表设计，和程序要变得更复杂。

如果要用MONGODB 来设计

员工表

{

"id":1,

"name: 'Sam',

"age": 36,

"department_level": [

{department:"HR",title:"职员"},

{department:“教育中心”,title:“讲师”}

]

"used_name":"Ted"

}

如何查询：

db.员工表.find({name:"Sam"}),  基本上查询就结束了，剩下就是在选择显示那些字段而已。

MONGODB 的colleciton的思路就是将复杂的表关系，放到一个collection用嵌套来处理，用冗余的数据，和KEY VALUE 的关系将两个或多个表的数据来进行体现，好处也是显而易见，方便，查询速度快。

2  大数据中的应用

如果你有多种数据库在系统中运行，想开发出一套能处理多种异构数据汇总，并将这些数据归一的数据模式，看上去很难，其实使用MONGODB 就可以解决问题，每种数据库的数据都可以变为 JSON 来进行存储，所有的数据都可以，实时（通过程序的手段，需要采集的数据变为JSON 放入MONGO），后面的事情就更简单，如果你还需要传统数据库或其他数据库进行数据的处理，就在将 JOSN 数据通过程序在塞入那些数据库，或者直接使用 MONGODB 加 其他大数据的处理方式，直接将结果计算出。

这就让我想起，马路上的转盘，只要有统一的规矩，和数据格式，MONGO DB 就是数据流可以汇总和分发的转盘。