sketch

validates 是方法，后面的都是参数

嗯，不过要换成 pg 不就是另一件事情了么，虽然都是 RDBMS

保留的话还要搞个 uuid 生成器，pk 都得改成字符串，reference 什么的也得改类型，都很麻烦，除此之外，32 字节的 id 其实也会影响速度的。

想要完全摆脱历史遗留问题，能一次做了就都做了吧，而且只要这个迁移过程不是手动的就不容易出错，自动化的脚本能避免人搞出的很多问题，只要停机时间可以接受，还是都改了比较好

Sketch 画的

对，还是选择合适的工具，没必要全盘否定 MongoDB

sketch

是的，我改下。。

确实有问题，改了

是，不过这边用的是 mysql5.7 支持 json 和 array 其实也还可以

最大的原因还是因为 MongoDB 有一张设计的不是特别好的表，单表数据量就上百万了，而且设计的时候将这张表设计为存储通用数据，里面存了各种来自不同业务的不同类型的数据，都是复杂的数据结构，如果整张表拆分的话，可能数量级就上千万了，整个迁移过程是没办法接受的，所以算是个历史遗留问题吧。。。

是这样的

@qinix [捂脸]

@hooopo 对了，当时还有一个问题，因为要做数据分析，MongoDB 可以直接跑 js 脚本，所以迁移到了 MongoDB，但是其实数据分析的需求并不多，目前项目里同时存在了 mongo 和 mysql，mongo 用来做数据分析，mysql 存业务数据

@hooopo 迁移到 MongoDB 的时候我还不在这边，也不大清楚具体什么情况，我了解的就是当时它们觉得无 schema 的数据结构更易于开发和字段的修改，但是其实这问题我觉得是不存在的，虽然字段易于修改了，但是每次修改数据结构都要洗数据。

我是觉得当时是为了解决不存在的问题，毕竟我们作为一个 CPU 密集型的服务其实是不太在乎数据库能不能分片，性能高不高的。