又看到一个从 mongo 迁移回关系数据库的，以前用一个 mongo 写小东西，后来重写的时换回 postgres 了。

两个数据库不一样，导致设计存储结构很不一样，所以最后方案只好手写数据迁移脚本。

其它工具类的没经验，等其它同学回答。

为啥要迁移回去呢？

#1 楼 @as181920 迁移回来的原因是什么？mongodb 有问题？还是业务不适合？

如果我做迁移，可以写 mongo script, 把数据生成需要的 json map 或 cvs 格式，然后写程序导入 mysql

只是需求而已！没其他原因！

@jeff_duan 我也考虑是这样，只不过想知道有没有人写过类似的！

#2 楼 @jeff_duan 很多关联查询，甚至 join 操作的地方，关系数据库比较方便，不是文档类数据库对口的应用场景，而且这个需求不涉及性能问题。

@as181920 说的对，这只涉及到需求

这个...我琢磨楼主只能自己写脚本搞了..

话说楼主之前有个帖子被删了.?

#7 楼 @as181920

很多关联查询，甚至 join 操作的地方，关系数据库比较方便，不是文档类数据库对口的应用场景，而且这个需求不涉及性能问题。

问一个问题，如果自己写一个 Mongodb 中使用的 join 方法，例如从一个表中取出所有数据，然后在另一个表中，使用 find 茶所有匹配记录，假设两个表都有索引，两表规模在十万左右级别 (属于杜撰，也许有更好地实现), 假设 Mongodb 最优查询算法的前提下，也远远比不上 MySQL 之类的关系数据库吧？

还是要自己写脚本导入吧....

#10 楼 @zw963 这个没有测试过，不敢随意下结论。 mongodb 通过 in 来写一个自己的 join，然后会有左右链接 join，in 的数组大小等情况，代码实现本身的性能等问题，还有开发测试投入。如果只是先快速实现功能的话，选开发快捷的就好。如果有时间折腾的话，可以测试研究，但是文档类数据库的强项/适用场景应该不是这种情况。 个人觉得如果东西多了，可以根据场景混合使用数据库就好，不强求一个技术解决所有问题。

如果有时间有技术的情况，也适合去自己真的写出来测试看看效果。