另一个角度的“业务向前，数据库向后”

今天《业务向前，数据库向后》的文章我也想表达自己的观点

    为了严谨一点我们把业务先分成靠谱的和不靠谱的。
     很多时候有一句话说技术是为业务服务的，这句听起来政治正确的话，我其实颇有微词。有时候其实业务人员一点都不靠谱。这种时候需要规范一下业务。需求乱提者有之。
    也有的时候是需求合理的，那么这时候就需要发挥技术人员的能力，尽可能完成业务诉求。我更多的时候能做到的是超过预期。（把军用卫星租过来，只允许你说不看，不允许你说收不到，这是电影《大腕》的台词），我日常也说只允许你说业务量太小，不允许说我做支持不了，当然这有个前提是按照我的设计做，而我的设计通常来说是大多人认为合理的。

那么基于靠谱的业务来说如何向前

      为了达成特定的要求，数据库要满足安全、性能等等各方面的要求。如果满足那么就是适配了。反之不满足的话，就只能业务适配数据库了。这怎么适配呢？就是业务说：我想。 数据库说：不，你不想。

    为什么会这样？因为数据库说我做不到啊。你行你上。

    比如听说（真事），一个用户原来用exadata（我真羡慕，我没用过，都没摸过），然后换成MySQL。为了降低成本。最后是变成了200多个MySQL。也不知道是降成本还是增加成本。最后机房都没地方放了。
   这就是典型的数据库拖累业务发展。

   这让我想到我上次去华为社区交流，华为说有些客户说，我们明明只是数据库的使用部门。怎么现在我们变成了数据库的基建部门了？还要去盖机房。

数据库其实是分场景的

     MySQL是不错的数据库，在互联网场景表现不错。因为他是轻量的。而互联网业务场景也是轻量的。
      但是其他场景还是非轻量的多。我们很多时候探讨发现，互联网产品离开自己的公司，到其他领域不是吊打其他数据库，而是被其他领域的业务吊打。很多场景上就不是分布式的最佳实践（我没说绝对），甚至是短板。再加上有时候极度的数据倾斜等在互联网场景中小概率出现在的场景就让不少数据库过不去了。
     很多所谓替换的深水区就是业务和数据库的矛盾。要么你就舍弃部分业务来适配数据库吧。

为什么讲数据库平替

     平替就是维持了原来的功能和性能。这二者缺一不可。否则原来能做到的现在做不到，这种做不到就是做不到。

      那么就是数据库向后，业务妥协一下。当然也不是不能妥协，很多时候领导讲究政治还是可以妥协的。只是我们要事先告诉领导做好妥协。

一个故事

     AB两个数据库和甲乙两个团队。甲团队用A数据库（功能和性能好一点），乙团队用B数据库（功能和性能弱一点）。技术路线不同而已。甲团队的不少业务问题和架构问题，不用考虑。数据库有。先于乙团队完成。（因为乙团队要考虑这个，要考虑那个，毕竟数据库没有这些功能和性能）。

    最后甲团队在公司胜出，因为先机就是商机。