小道消息：某国产数据库迁移中途失败

最近与某国企集团首席专家聊天，敢情国企集团很喜欢“首席“这头衔！

聊天内容是该集团旗下的某个子公司进行国产数据库迁移，迁移一半时，复杂的SQL无法兼容，导致无法迁移下去。厂商建议进行应用改造！下面技术人员在骂娘！ 

   我就觉得奇怪，一年前该集团都进行很多家国产数据库POC，最终确定这家比较可以。怎么实施迁移的过程才发现兼容性问题。 首席专家说只是做了基础POC，没有做全面的POC。 难道做个全面POC很难吗？ 不就是把所有系统里的SQL抓出来丢进某国产数据库跑跑看看。 估计该国企下面技术人员也是人菜证书多那种。

该国产数据库几年前还请了两个ACE专家去领奖，好像是感谢ACE的宣传和造势！  我以为是请ACE专家进行SQL兼容性测试，毕竟ACE所在的公司都是大伽。要点业务SQL是件很容易的事情，或者帮忙抓所有复杂的SQL进行测试，看看是否对ORACLE SQL兼容性！ 看来我是想多了。

该国产数据库 我现在叫它泼妇DB吧！ 我以前写了个帖子说，它真的是套了个壳，连进程名字还是PG的，连版本号还是PG的。我一年前跟该国企首席专家说泼妇DB只是简单套了美国民间组织的PG数据库，很受美国PG组织的影响。比如BUG和安全漏洞！ 该卡脖子依旧会卡脖子。

我花费几周时间改造一下 PG 17 感觉很容易啊

不是我在这里胡说八道的，魔天轮有人发文章写国产数据库文章里面贴了出来！

听首席朋友说，领导是个红脖子，偏爱民族企业。这些民族企业除了菊厂外，其它两家要么在香港上市，南非控股，要么在美国上市，日本控股！这集团领导脑子真的可以。 

所以这个就是没有办法的事情了！ 还听说某银行行也对国产数据库一哥进行了POC，也测试出一堆问题。

其实任何国产数据库兼容ORACLE SQL语句都有一堆技术问题，技术问题不重要，都可以通过应用改造进行解决。

对于技术人员来说 问题重点就是要进行全面测试，这点其实不难！把所有业务的中间件，部署一套，WEBLOGIC +JAR。或者是C/S架构。走一遍业务流程。各种季节性，阶段性业务流程都走走。看看能报出多少SQL不兼容的事情。 对比哪家国产数据库兼容最好！

当然哪家最好也是没有用的，领导偏爱哪家就只能这家。问题是把问题测试来是对自己负责任的。 

你们看这国庆节放假，能放假安心吗？ 领导是不是要求国庆加班去解决问题，进行应用改造。

怎么样的数据库才是真国产？

分享提取MYBAITS.XML的SQL C++语言

国产数据库 SharkDB 17.1 源码安装

上面中间是我写的C语言程序是把XML里面的SQL解析出来，能解析多少是多少！ 拿去用吧！ 解析出SQL丢进某国产数据库运行看看。

很多专家为什么位高权重，却越来越傻X？跟这其实是一个道理。在傻X的光环下（真的就是光环，普通人不要站在自己的位置上质疑这一点），他们往往活得更滋润。

所以，御医治不好病是常态。现在，动不动有人冒充自己是御医的后代，招摇撞骗，其实，从业务素质上来看，御医治不好病才是常态。御医是庸医的另一个身份而已。那些骗子不读书，当然不懂这一点，以为御医就是高手，这跟以为专家都是高手一样，属于误判。

很多人不懂“专家”是个贬义词，其实20年专家和教授，以及老师都是贬义词。专家全称是专门骗大家！

比如ACE专家，就是ACE专门骗大家！