该课直播地址：
https://live.polyv.cn/watch/2777655
免费，需要提供个人与公司信息（提供假的也可以
在群里看到朋友发的，对 MongoDB 挺感兴趣，之前有公司同事使用过，了解过一点，自己没有实际的应用。
正好讲的还是数据结构的设计，所以就来听一听。
首先是讲的挺不错的，但是比较浅。
他首先讲了MongoDB 与关系型数据库的差别，但是说实话，我觉得就他在视频中所讲的几种场景来说，我用Mysql同样也可以实现，对于我们开发来说，更应该在意的也许应该是二者同样模式下使用的性能差距。
然后他讲的一些应该遵循的原则在我看来基本是与数据库无关的，当然我对 MongoDB 并不是很了解，所以评价难免有失偏颇。
谈一下他举的几个例子吧
这个是个很经典的问题，我早年开发时，认为在复杂业务系统里应该是数据仅有一份，不做任何的冗余数据。也就是图上左边的做法。
这样做的好处是你有清晰、干净的数据模型，可以较好的应对需求变更的各种改字段加字段，坏处是查询需要明细信息的列表时需要联查，依数据量判断性能可能比较低。
在我看到的一些业务系统中，通常是右侧的做法，但其中的大多数完全不考虑冗余更新，或者不能处理好冗余更新问题。
视频中老师的态度是认为应该看这种设计对于你的功能使用是否有影响，考虑两种方式中哪种使你受益更多。
在我看来这个问题主要取决于系统的性能要求，若无较高的要求就可以使用第一种，这对开发的好处是显而易见的。
而使用第二种的问题是取决于如何在代码中组织这种冗余数据更新的操作，这又是代码如何分层分块去支持这种模式或是如何做统一封装的问题。
如果依赖各个功能的编写者去做冗余更新，那明显属于是走向屎山，时间长了必然出现漏更和错更。所以需要代码中有某种模式去支持。
这也是一个很经典的问题，设计模式中有一个理论就是 聚合优于组合。
我看到这两种模式的差别时想到的是第二种可能还不优于第一种，唯一的好处大概是减少了重复的多余数据：相同的id这种。
视频中老师说到这是一个IOT数据的例子，说到我们在使用这类数据的时候它通常不会是取出特定一条数据，而是时间段数据去看数据的趋势。这个时候第二种模式的优势就体现出来了。
因为我以前做过一个记录GPS移动轨迹的功能，数据的特征和这个例子是一致的，而我用的是第一种方案。当时就存在两个问题，一个是数据量偏大，另一个是数据模型过大。
前端需要一次提交几百条记录上来，很容易超时，还有请求包体过大没有进入到API这类问题。
这个就听有意思了，是我当时没想到的一个方面，没有去压缩这个数据，视频中的老师进一步将记录的 temperature 压缩为一个数组。
这个做法确实很棒。
业务数据模型的设计应该是脱离数据库的，但当它落实到某一种数据库时自然也就变成了针对一种数据库的设计。
我们应该考虑不同数据库在使用上（主要是查询）的差别，除此之外主要就是性能上的区别了。看某种设计下，两种不同的数据库查询效率的区别。
因为我们可以忍受查询的麻烦过程，却无法解决数据库本身的性能问题。在网上随便搜了一下，有些测试说 MongoDB 和 mysql 性能持平。这也不能随便相信，最好还是自己去测试一下。
反正我现在觉得mysql挺差劲的。有时间还是了解一下 MongoDB 在Json查询上提供了那些便利。
年底了，没什么工作内容，发点乱七八糟的碎碎念。