确实干过一些有问题方案。

方案 1：一次接一个电话就到会议室，简单告诉我背景。就说原来有个 A数据库，后来由于种种原因吧，有了一个 B数据库。业务在使用过程中就发现 B数据库必须用到 A数据库的数据，目前需要 2个表。且一致性和实时性非常高。要求解决，且（重点来了），不能增加开发工作量，最好 48小时以后就可以用。

数据库是同构数据库 Oracle。

基于以上的条件我只能给出了在 B数据库上建立一个到 A数据库的物化视图的方案。简述了一下，与会者都觉得可以接受。

不过我说了一句，如果 AB两个这么紧密，建 议这两个数据库就应该合并。说的时候我就知道，这不可能被同意。合并数据库的动作多大啊。

最终物化视图上线启用，各方反馈效果很好。故事原本到这里如果结束了就好了。但是没有。有一天有人说需要给源端（上游）的一个表做变更（增加字段），问我怎么办？我说如果目标端（下游）也需要这个字段的话，那么就要重建物化视图。然后我顺便去看了这个数据库，结果发现当初说好的同步 2个表，现在有 50多个表，每 5秒刷新一下。原来是开发觉得这样用一时，一时爽。一直用，一直爽。加加加。现在上下游数据库很大的 负荷来自这种刷新。

这就是这个方案的问题。最终还是用 OGG这种 CDC技术替代了物化视图。两端的 负荷下降了 40%以上。

其实我想说：

单机（含高可用）是最好的架构，没有之一。

方案 2：

有业 务说她们有很大的物联网场景。问我选什么数据库。既然是物联网场景选时序数据库似乎是非常合理的。时序数据库其实和关系型数据库很像。说一点不一样的：

1基本不会变更表结构

2基本不会去修改数据

3基本不会去删除数据

4允许少许的数据丢失

看！增删改查去掉了两个，数据还能丢一点。比关系型数据库要求低了好多。没有这些约束条件了，那么写入场景就嗷 嗷快了。

结果用了一段时间以后我回访发现，实际写入量来说 MySQL应付绰绰有余。结果现在多了一种技术栈还是 NoSQL的。

问题还不算完。业务 方说，这些传感器的数据单独在一起发挥不了太大的作用。如果能和交易订单以及物流信息联系起来，那么就可以知道运输和出入库是不是一致。能起到监管和风控的作用。听到这里我不禁想说，您早说的话，我直接让这些写入生产库（毕竟这些数据也不多，而且也是生产数据）那么问题就都解决了。

单机（含高可用）是最好的架构，没有之一。

方案 3：

微服务和中台化这些概念是我个人觉得 是：淮南为橘,淮北为枳。一个项目团队说要做中台。咱们能拦着吗？根本拦不住。然后说要把原来一个schema下的表拆分到不同维度的数据库 中去，拆分后要隔离。我就 想那么就上PDB吧（原来是Oracle11G，现在是Oracle19C）。

做方案时候我还问，你这些本来一起的为什么要分开呢？答：因为要做中台。

我又问，那么你这些分开了以后怎么关联呢？答：之间不关联。

上线后发现，不关 联日子过不下去。不仅PDB要关联，而且和外部其他数据库也要关联（因为要做中台嘛）。中台这个连提出的马云都没搞明白，我至今也一样没搞明白。结 果，各种数据同步。

如果再给我一次机会的话，我绝对不赞成做这样。

我想说：单机（含高可用）是最好的架构，没有之一。

如果说总结就是事先没有深入了解业务，这也是普遍存在的现象。甚至有的业务自己都没能了解自己的业务（规划）。而仅仅我这三个失败的案例看来，数据库集中在很大程度上可以抵御这种不确定因素。

一定会有人反驳我说鸡蛋都在一个篮子等等。是的。会有风险，但是不一定发生。而以上问题是全部都已经发生的。两权相害取其轻,两权相利取其重。意思是:如果你遇到难处,你就选择其中危害轻的事情。如果两件事情都对你有好处,你就做其中好处最大的事情。