完全舍弃Mysql关系型数据库，转为使用文档性数据库mongodb，敏捷开发更得心应手了
1.表结构与字段快速变化
需求的快速变化必然引起表结构的快速变化，然而传统关系型数据库，要修改表结构必须使用alter，create等语句。为了保证项目中测试数据库与正式数据库或其他数据库结构一致，有了flyway这种东西，但实际使用中依然不便。首先flyway以sql文件名版本号的形式来维护数据库版本，项目时间一长，flyway文件夹的sql文件数量会变得非常庞大，另外一点，两个开发者同时想要修改表结构时，极易产生版本冲突，两人可能在同一时间都提交了同一个版本号的sql文件，导致flyway执行出错，这种问题处理起来及其麻烦。另外如果一个开发人员本地代码的pojo类与数据库表字段对不上（已经被另外一个开发人员的flyway更新），执行指定字段的select或insert语句是会报错的，此时他只能等待另外一名开放人员将新版pojo类提交。
得益于文档型数据库的特性，灵活的表机构形式，无需修改表结构，在插入新数据时，自动会新增字段和表，不再使用alter，create语句，我们只要修改pojo类，自动可同步数据库到新的表结构。不用管数据库中表结构是否与pojo属性一直，进行插入和查询都不会产生报错，大大降低开发人员的耦合性。
另外确实有一些框架可以实现通过扫描pojo类，自动修改数据库表结构的，达到抛弃flyway的效果，比如 https://gitee.com/sunchenbin/mybatis-enhance 这个框架，但依然解决不了一个开发人员等待另一个提交pojo类才能正常操作新版数据库的问题。与其花时间来做pojo与表结构的同步方案，不如一劳永逸的使用mongodb来解决表结构问题。
2.主键生成策略
mysql的主键生成策略不能算好，要不然使用自增数字，要不然由程序生成一个uuid。自增数字主键在数据库导入导出时偶尔会有一些问题，而且无法保证一条数据的id全数据库唯一（这个有时候挺有用的），而且还会暴露数据库的隐私数据，比如新注册一个用户，看id就能得知系统总用户数。由程序生成uuid则不利于索引的建立，查询速度慢等。而mongodb的主键生成策略完美的考虑以上问题，默认生成的主键既有唯一性又有索引优势。当然也有一些mysql主键生成库可以生成出类似于mongodb的主键，但和上面说的表结构问题一样，能由数据库自己解决当然是最好的。
3.连表查询
关系型数据库的连表查询能解决很多问题，但在大公司中已不再推荐使用，因为很难做数据库优化，数据量庞大时查询时间很慢。需要连表查询时，先查出对方id集，再使用in进行包含查询，可以很方便的走索引，而且分库的时候很容易修改。这样使用的话，实际是将关系型数据库用成了近似文档型数据库，表之间不再产生关联。因此为什么不直接一步到位使用文档型数据库，彻底放弃连表查询。
4.集群与读写分离
Mysql实现集群和读写分离需要第三方组件，搭建难度较大，而且orm中要实现读写分离，即写入操作只在写入库操作，读取操作要分散在多个读库中，还是比较麻烦的。而mongodb天生对于集群的支持非常好，只靠自己就能建立复制，分片集群。而且集群读写偏好全部在uri中就指定清楚了。无需在orm中编写多数据源读写偏好代码。
5.总结
使用mongodb确实能解决很多敏捷开发中的数据库问题，多年使用mysql经验后，发现我们为了使用好mysql，给它套了太多太多东西了，mybatis、mybatis-plus、jpa、flyway、mycat等等。依然没有把mysql这头猛兽驯服，还增加了学习曲线的陡峭度。为何不换一种思路，直接放弃mysql关系型数据库，直接投入文档性数据库mongodb的怀抱，这才发现，原来很多问题都不再是问题了。
以下是本人根据以上理念。基于spring-data-mongodb构建的一套orm工具mongoHelper，为敏捷开发的项目封装了不少功能，使用mongodb后，很多困扰多年的数据库表结构问题迎刃而解，再也不必花大力气关注数据库表结构版本了。
https://gitee.com/cym1102/mongoHelper
以上是 完全舍弃Mysql关系型数据库，转为使用文档性数据库mongodb，敏捷开发更得心应手了 的全部内容， 来源链接： utcz.com/z/513374.html
