话说，这两天搞数据真的累！
以前用的关系型数据用sql真的很好做关联查询，即使是小白如我也能很快搞定需求。但是mongodb不是那么一回事啊。
网上查资料也要吐血了，搜索不太支持自然语言，我的需求是对比两个表数据，专业名词叫“多表关联查询”，但我的问题不就是我不知道“多表关联查询”能解决我的问题吗！
所以，很多时候就得一点点看语法，但很多大神写的内容又太“柴”，就不易上手理解吧…
so，好不容易趟了一次路，我还是自己做个简单的输出免得回头忘了吧（大神有好的方法请多指点）。
先描述一下需求场景：
整体情况：
我现在手上有一家店的信息，它被存在在两个表、这两张表分别放在两个数据库里。这两个表有的信息是相同的，有的信息是各自有的。
需求1、我现在需要确定用shop_id作为关联标识靠不靠谱；
需求2、对比下相同id的两家店，店名是否相同。
数据存储结构
第一个数据库叫A，collection名叫A1，字段分别是shop_id、shop_name，数据总共72条。第二个数据库叫B，collection名叫B1，字段分别是id、shopname，数据总共423条。
要处理这两个数据，第一个问题就来了，
mongodb怎么进行跨库连表查询？
答案是query直接支持的是没有的，需要把两张表放到同一个数据库。
吐槽一下，这个问题我在百度搜了老半天都没有什么简单易懂的方法，用google直接找到studio 3t（操作mongodb超好用啊）支持的功能。
简单说就是可以使用import功能，把B库里的B1导进A1里，3w多的数据只有3s就完成了！（操作视频可以看Import a Mongodb Collection From Another database）
操作完后，A1库里现在有一张新的collection叫B2了，数据结构跟B1是一样的。
需求1：用shop_id作为关联标识靠不靠谱
方法1：使用inner join
Studio 3t棒的地方在于可以支持简单的SQL查询。但是要注意，它支持下的语音跟SQL还是有一点细节差异的。（具体可以看Studio 3T Supported SQL joins）
最后写出来语法是这样的：
select A1.shop_id from A1 inner join B1 on A1.shop_id=B1.id
简单来看跟sql的区别就是：不能像sql那样使用*号也不能去定义表名（语法写错了是查不出来的）。
刚才有说A1总共72条数据，B1总共423条，此时结果如果有72条，那我们可以说A1的shopid完全能跟B1的对上了。但这个方法缺点就是，如果结果不是72条，你想知道哪些对不上，就看不出来了。
所以，我们还需要方法2.
方法2：使用lookup
我又要吐槽了，mongodb的lookup相较excel简直是辣鸡。
我们直接看具体用法吧，我不写带术语的内容了，想看的话可以看这篇（MongoDB中的多表关联查询（$lookup））
lookup语法可以做到，在A1数据结果上，加一列B2的店铺信息（前提是id匹配上），结果如下。
此时，如果shop_info结果是1element，我们就知道哪些是对应上的B2有数据的，如果是0那就是B2里没有id相同的店的信息了。
语法是这样写的（要在mongodb shell里执行哦）：
use A;
db.A1.aggregate([
{
$lookup:
{
from:"B2",
localField:"shop_id",
foreignField:"id",
as:"shop_info"
}
}
])
写到这里，不知道跟我一样是小白的你，有没有发现，lookup是不能很简单地解决需求2的。那么，咋办呢？我要祭出excel大法了！
需求2、对比下相同id的两家店，店名是否相同
为啥用excel？
原因1、对mongodb的语法不够熟悉（mongodb语法），相信很可能是有解决办法的，但是实践成本比较高；2、实际中对比的数据量不是很大，总共是3万多条数据，excel还能加工得过来。
好了，开干。
第一步，导出A1和B2两个collection
这个在studio 3t基本是傻瓜式操作，详细可以看（Export MongoDB to CSV (e.g. Excel)）
第二步，处理csv的编码格式
直接用excel打开csv很可能是乱码，原因在于文本编码格式。
处理办法：
将导出的csv文件后缀改为txt。打开txt文档，点击复制，再对新文档点击存储，存储时将文本编码从UTF-8改为GB 18030，同时，文件后缀再次改为csv。
第三步，使用excel来处理数据
我个人常用的excel处理方法，就是vlookup以及数据透视表了。
相对来说，都比较简单，王上资料也很多，就不在本文赘述啦。
总结一下
在这个探索过程中，一方面确实感受到了mongodb存储数据以及处理数据的灵活性，另一方面，也发现了关系型数据库严丝合缝的优点了、好查呀！
当然mongodb的优点背后就会有它的局限性，我会觉得妈呀数据好乱啊怎么做个关联这么困难。
嗯~就先记录到此。
