自己原文公众号： https://mp.weixin.qq.com/s/dwgB4pwqhahTdRan_sKQWQ
我以前一直说单机是最好的架构。这里的单机是指的一套数据库比如PG的集群，oracle的RAC、MySQL的MGR。我反对分库分表，不管别人怎么说我始终坚定这么认为。今天开始一个系列来说明。后续我打算有数据同步篇章、分库篇章、融合篇章等等等等
多年前在一家公司有这么一个场景。一个门户网站下属N多子平台。希望在任何一家平台注册，在所有平台可以登录。
这里有几种方案。
方案1，各家独立自己会员数据库，你们想想一下就是N个平台的数据库会员要进行注册同步，注销同步，状态同步等等。这个最终的问题就是总是有数据不同步，不是这里少了，就是那里少了。因为一个要对N-1个发送和接收。而且由于开发水平有限接口效率又低。其实接口底层几乎都是SQL，本来是透明的，包装了一下穿了一个马甲大家不知道里面是什么。
方案2，建立一个数据库大家都到一个地方统一去。当时N个平台就是一个数据库上的N个schema。也就是说授权一下select就行。这个方案获得了所有开发的赞同。理由是所有接口都不用做了，耶。工作量减轻。而且效率比之前的接口高了至少100倍。因为大家都用一个一模一样的SQL，不会因为不同团队水平不同效率不同。
最重要的之前很多问题都没有了，用户也不抱怨了。以前总说技术为业务服务的。业务哪里懂技术，用简单的解决了问题。不必要高大上的，比如微服务或者中台，有的时候可能还解决不了问题，结果制造了问题。关键是中台一直是一道送命题。
一次是偶然，两次是必然。又有一次一个领导下属N个团队，各个团队相互协作。因为每个团队都是其他团队的上下游。每个团队都是流程一个环节。说到这里大家可能猜到了。对，每个环节一个独立的数据库。重点还是都是异构数据库。一个流程所有团队都要参与才能走得通，每个异构数据库要走通必然要经过接口啊。一个需求变更，N个团队一起动。而且每个团队都说人手不足。
最后不得已所有异构数据库都变成同构，而且合在一个数据库实例里面。又回到上面说的：所有接口都不用做了，耶。工作量减轻。而且效率比之前的接口高了至少100倍。流程也短了，甚至有些表都合了。数据和功能都整个了，然后开发人员也整合。人手也不至于不够了。一举多得。看到这里其实发现了，很多不应该分开的数据库，是为了分而分，结果最好对自己形成了反噬。
其实一个需求来了，把控需求的人算算开发人员薪酬X几个月然后这个成本和需求带来的价值比比，就知道有些需求不上才是最好的。
