确实干过一些有问题方案。
方案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要关联，而且和外部其他数据库也要关联（因为要做中台嘛）。中台这个连提出的马云都没搞明白，我至今也一样没搞明白。结果，各种数据同步。
如果再给我一次机会的话，我绝对不赞成做这样。
我想说：单机（含高可用）是最好的架构，没有之一。
如果说总结就是事先没有深入了解业务，这也是普遍存在的现象。甚至有的业务自己都没能了解自己的业务（规划）。而仅仅我这三个失败的案例看来，数据库集中在很大程度上可以抵御这种不确定因素。
一定会有人反驳我说鸡蛋都在一个篮子等等。是的。会有风险，但是不一定发生。而以上问题是全部都已经发生的。两权相害取其轻,两权相利取其重。意思是:如果你遇到难处,你就选择其中危害轻的事情。如果两件事情都对你有好处,你就做其中好处最大的事情。
