说多了都是泪--由开发自主选型

     最近有些好学的同事向我咨询数据库选型，我觉得这是好事。最起码问专业的人，比起自以为懂数据库的开发来选择要好的多。我从使用场景、数据量、优化器以及单体还是分布式等等很多角度来说明各种数据库的选择。这年头数据库铺天盖地，尤其是国产数据库（有几个优秀的，但是大部分不怎么优秀）。这种情况下，开发质量不高的程序，可能在Oracle DB2这样的数据库上能运行良好的，在MySQL等开源上运行的就不行了。我上周刚处理了一个这样的案例。这几年不少去O，但是没人提去DB2和SQLSERVER，被去掉了吗？可能因为O是第一，都想打赢第一。其他的数据库说考虑一下我的感受。来打我呀。

     我之前也有一个案例，在MySQL上运行很好的，但是到了国产上就GG了。感兴趣的请往前找找。所以换国产要大量的适配，比如改写、比如重新设计、甚至必要时候推到了重来。这是极有可能的。具体如何选，做数据库的人最知道。开发基本不知道数据库有多少坑，因为即使Oracle MySQL这样的一般开发人员也未必都知道应该怎么做。即使从Oracle到MySQL上，碰的头破血流的也有的是。当然其实任意两种数据库切换都是带来各式各样的问题。

    今天还遇到一件事，看到开发同学要清理表，问问为什么？说这些表是记录分布式数据的。重点是整个系统就一个数据库，单实例数据。采用了分布式。这在做数据库的人角度是玩命的不理解啊！ 单实例数据库用毛分布式事务？答复是服务拆分为了数据库的一致性。比如甲向乙转账的场景，甲的扣款服务和乙得到收款服务两个要一致。    

     听到这里但凡做过数据库的人都想哭了吧？

    因为在几十年前ACID的基础就告诉我们，数据库就是要把这两个操作放在一个事务中来保证一致性。而如今微服务的居然把他们拆开，要用其他的来保证。（就实际情况而言，看上去没保证，所以后台要做处理）。我一向认为微服务的最小单元是事务，而不是SQL。也不知道现在为什么都这样来做？来打个比方吧。本来我们喝水小便都不用我们操心，生下来就自主完成的。现在做了一件事就是从胃接一个管子出来，到一个瓶子，再从瓶子接一个管子到膀胱。（例子有点不雅，但是事情就这么个事情。是不是感觉多此一举？）

    这种事情太多了，从A数据库到B数据库，方法很多可以用CDC，也可以做程序从A拿数据搬迁到B等等。但是现在不少人会设计一个程序M从A中拿数据到消息队列，再做一个程序N从消息队列中拿数据到B。

      你看事情总是相似的。