MongoDB 设计深入思考与反思

之前是用过MONGODB 很长一段时间的，想想也有快3年的时间了，在这篇文字前是有一篇关于MONGODB 的文字的也是粗浅的说了说关于数组和嵌套的问题，今天偶然看到一篇文字，说是不深入的学习和理解，在努力也是白费。想想是这样的，如果经常蜻蜓点水的学习，虽然速度快，但很快就会忘记。所以这篇文字准备好好的捋一捋，MONGODB 中关于“集合”方面的设计和反思。

首先MONGODB 由于没有事务这样的东西，（4.0有事务但不是传统数据库的事务，所以不要搞混），所以一般来说设计MONGODB 的思路大致可以总结为

1 一对一 的关系

2 一对多的关系 （有可以分为一对少数的关系 ，一对多数的关系）

3 多对多的关系

最后可以归结为文档的设计是，嵌套，还是引用的问题。

这里会着重一对多的思考和其他的一些想法，一般我刚使用MONGODB 的时候见到或有的设计思路大部分是将一组子文档嵌入到父文档中，但事实上多层的嵌套会给后续的数据处理带来一些麻烦。

在一对多的关系中，分为一对少数，和一对多数的问题，而这样的数量的区别就会产生设计上的一些区别。因为要考虑数据的提取和修改中产生的麻烦，这就牵扯到另一个问题，MONGODB 到底是为空间服务，还是为时间服务，个人认为，大部分的数据库的设计中，都存在浪费空间来换取时间的想法，其实也是为了性能。MONGODB 的设计也是如此。

我们举一个例子大家就应该明白我上面说的

例如我们有一个二手车销售的项目，如果我们用传统的数据库，我们会怎么设计？

这里举个简单的例子，至少我们要有5张表，如果还要包含照片，身份证信息，或者保单，车辆照片等等，那就更麻烦了。

而如果我们改换门庭，将他变成MONGODB 的schema 的设计，则一个"集合" 就可以将这个设计解决，更方便的是，如果业务有什么其他的需求，我们也可以在后面的记录中添加进来。

当然上边仅仅是举一个例子，可能业务并没有那么简单，并且还有一些和事务有关的东西存在，需要一些失败后回滚的需求。（其实可以研究MONGODB 4.0的事务）。

所以这才有很多单位并未使用MONGODB 而大批传统的 RDS 还在使用。

回到刚才说的，用空间换时间，到底怎么换了，大家可以注意，如果购买车辆的人多次购买，或者车辆的车型信息，在或者经销商的信息更改等等

都会在这张所谓的订单表进行信息的重复，因为我不想UPDATE，而是通过version信息确认最新的信息版本（当然在非业务时间也可以处理掉那些不需要的数据），其实就是在消耗大量的空间，而基于时间或版本信息，基础上我们只要知道（插入数据，和查询，而没有UPDATE 以及对程级别的delete操作）这张订单的订单号，相关的信息就全部能查出来，所以在查询中一定是比传统数据库查询要快速的。这就是所谓的空间换时间，信息的冗余，可以带来的是时间消耗的缩小。

在MONGODB collection 的设计中的另一种用空间来换时间的方式，就是双向关联。使用这种方式其实也是为了更快速的查询，而浪费相关的空间。我们可以举个例子

如果我们是一个地产公司，房屋的销售人员 和 房屋之间的关系就是多对多的关系，一个销售人员可以销售的多个公司的房屋，而一个房屋也可以被多个销售人员同时进行销售，其实严格来说，这还纯属于我想表达的意思而强拉硬拽出来的例子

db.apartment.insert({
    "apartmentNO":"128",
    "sales":{
        "sale1":"张小雅"，
        "sale2":"李晓蕊"
        },
})
db.salesman.insert({
    "salesman":"张小雅"，
     "saleaprtment":["109","128","320"]
})

通过查询销售人员可以得知某个销售人员的正在销售的房屋，通过查询房屋的情况也可以得到每个房屋正在被那几个销售人员销售。

说了这么多，其实如果你看到这里，使用MONGODB 可以将多个表合成为一个集合，多表连接查询的时候，可以将信息冗余，存储在两个或多个collection，这样做的好处就是节省数据访问的时间。