MONGODB那种设计更适合

最近工作的场景，发现很多场景适合MONGODB 发挥它的长处。

比如经常变动的需求，有些需求在开发告一段落后，预估还有变动看似不合理，其实在现实中处处可见，需求不完善，需求不明确，需求由于某些原因修改。 

这样的事情传统数据库处理上会比较费劲，除了表设计上要费工夫，改来改去，同时表设计时还要考虑性能问题，等等，让本来可以关注应用开发的developer，必须要费精力在 系统性能和设计和优化上。当然必要的设计和优化是应该的，而有些数据库必须要精益求精，否则就还你颜色。

相对来说，有些企业和开发人员更细化在合适的场景去使用“皮实”的数据库，来解决适合的业务场景，也让运维人员减少，ICU的“风险”.(老大半夜给你打电话，心惊肉跳的，不去ICU才怪)。

所以，如果可以MONGODB 数据库其实是一个好的选择。但很多人初用MONGODB ，不大清楚MONGODB 的设计方法和规则，这点是让人遗憾的，好东西只有知道怎么用才能更好的服务。

MONGODB 主要的设计方法不外乎

一 对 少数几个，一般来说这个场景是我们比较常见的， 例如我们想记录某个产品的组成部分，例如薯片，是由 棕榈油，马铃薯粉，调味粉，盐组成的。我们可写些什么？

{

  name: 薯片

  type:   膨化类

  原料配料：[

{组成：马铃薯粉， 来源：进口，地区：俄罗斯}，

{组成：棕榈油  ，  来源：进口  ，地区：菲律宾}，

{组成：调味粉，  来源：进口， 地区：日本}，

....... 等等

            ]

}

一对 很多， 这样的情况，例如运动产品零件，每个机械上几十个零件，而上面的设计明显是不大合适。

怎么办，我们可以对建立两个collectiton，甚至多个collections , 以下仅仅为举例，考虑不周。

例如我们建立 机械 collection

{  机械名称：跑步机

   类型：民用，

   机械编号： 329839843

   包含零件: [

  objectID('039048dx89c8'),

 objectID('03948dx89c8'),

 objectID('039048fx89c8'),

  objectID('0390dfdx89c8'),

........

                  ]

}

而具体每个零件的信息则在另一个collection中

零件

{

 _id: objectID('0390dfdx89c8'),

零件材料：金属，

零件来源： 美国

零件尺寸：3.8M

......

}

比如要查询这个产品的零件组成

我们可以这样做

产品= db.产品.findOne({机械编号： 329839843})

产品零件= db.零件.find({_id:{$in:产品.包含零件}}).toArray();

两步将数据获取，大家可以注意，这样获取信息看似需要两步，不如传统数据库一个SQL 就可以解决问题，但实际上，从获取信息的速度，以及日后的维护和设计上来说是好的，

例如，这个产品又增加了几个零件，你要怎么办，建立字段，然后把这些零件加进去，那过两天，零件的数目又减少了怎么办？

这对MONGODB 这样的额数据库是在合适不过，对于灵活的经常出人思维左右的任务，他都能比较好的完成。

这里再举一个极端的例子，我们将日志存入到MONGODB ，比如我们有上千台机器的应用日志。

我们可以根据机器的信息建立一个collection, 同时，建立一个collection来存日志，（MONGODB的吞吐量，你不用担心，只要你给内存，SSD，纳秒也不是问题）。

机器信息：

{ _id:objectID('dfa384782374'),

  name: 数据库

  ip地址：192.168.91.12

}

告警信息：

{

  时间: ISODATE("2019-09-09T09:23:09.234Z")

 信息:'memory OOM'

host:objectID('dfa384782374')

}

查询也是方便的，

host=db.机器信息.findOne({ip地址：192.168.91.12})

最新日志报错100条

msg=db.告警信息.find({host:host._id}),sort({时间:-1}).limit(100) 

其实MONGODB 的collection的设计方式很多，当然需要根据MOINGODB的方式来设计，例如是嵌套多好，还是数组使用多好，是尽量把信息忘一个COLLECTION 塞，还是分散点好，key  的设计有么有注意事项等等，这都是在设计MONGODB 要考虑的问题，第一点你要熟悉你的使用场景和你的业务。