有些朋友总是无法理解为什么会有用户有这样那样的应用场景。有些互联网企业的朋友觉得数据库系统只要把应用架构搞好了就万事大吉了，微服务架构，领域建模就解决了绝大多数问题了。但是传统行业的用户就会觉得数据库强大，应用才能好用，这一点让很多互联网出身的架构师感到十分不解，明明MYSQL就能搞定的事情，为啥离了ORACLE就玩不转。二者的观点差异巨大，而且相互都无法说服对方。

实际上这两类人都是在自己的信息茧房里时间太长了，对自己行业理解很深刻，对对方的行业只有肤浅的认知。曾经有个一直在各个互联网企业工作的朋友说，他无法理解那些使用存储过程的企业，把业务逻辑放到应用系统里不是更方便吗?可能他周边的应用开发团队水平都是相当不错的，没有遇到过给传统行业开发应用的开发人员。在这些团队中，能把SQL写明白的都已经算高手了，不要说领域模型了。

曾经有个国企的IT部门领导和我聊过他们的数据库从SQL SERVER迁移到云平台DRDS的故事，原来他手下的开发团队完全搞不定，最后他们的研究院重新组织了一支百人团队接过去干这个活，每年人力成本增加两三千万。传统企业原有研发能力与互联网企业的差距是巨大的，原本的人力资源成本也要低很多。

前几年某央企一个核心业务系统升级，当时在互联网企业的帮助下决定全面上云。花钱请了互联网公司的咨询顾问按照领域建模，把业务划分为二十多个领域。决定用二十多个RDS MYSQL领域数据库来替代原来的一套跑在2台8路服务器或者四路服务器上的ORACLE RAC。开发刚刚开始不久，开发商的DBA发现ORACLE的有些功能MYSQL实现起来比较费劲，于是不得不放弃MYSQL，改回ORACLE。但是一套RAC拆成20多套，有点太浪费了。于是把这二十多个领域库又合并成了4套ORACLE数据库。

这还没完，因为一套库拆成四套，只会写SQL的研发人员发现很多原本一条SQL能搞定的业务逻辑现在做不了了。而这家企业又因为当年SCN HEADROOM问题，不允许使用DBLINK。于是天才的互联网架构师继续在上面打补丁，用OGG在这些数据库之间来回复制数据。久而久之，这四个数据库之间居然创建了上千条复制链路。问题又来了，OGG的复制延时又是个大问题了。

传统行业，甲方的研发能力就如此了，一个月万把块钱工资的码农，你非要他们干出大几十万年薪的人才有能力干得出的活，是不是也太难为他们了。一些大企业虽然不差钱，但是干啥事都是有规矩的，钱也不能随心所欲地花啊。正因为这样的情况存在，才需要国产数据库能像O记那么强大，也才会给优秀的国产数据库更多的机会。

目前数据库应用又面临一个新的挑战，在国产数据库替代工作中，有很多领导依然受到互联网“先进”思维的影响，不考虑自己与互联网企业巨大的研发投入和研发能力差距，盲目全面照抄互联网企业的作业，风险还是很大的。