最近工作的场景，发现很多场景适合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 要考虑的问题，第一点你要熟悉你的使用场景和你的业务。
