首先我们要肯定国产做到好的地方。比如很早就有一些国产厂商在做数据库，早到了2000年左右。那时候的国产厂商是为了长期发展而做的。尽管做的可能还不够好。但是也在有些领域和行业能用。我们要说的不是这些坚持长期发展的厂商，而是一些“变味”了的厂商。随着信创成为国家战略，国产数据库领域就出现了一些“变味”了的厂商。当然这种“变味”的不止国产数据库。大数据、区块链和人工智能都有这样的。这个“变味”是说打着信创的大旗，站在制高点上来抢钱的。理想状况来说，是国产的和非国产的在技术方方面面差不多，还比非国产的便宜（毕竟国外的人工贵），或者价格相差不多，那么这肯定都是天大的好事，毕竟还是用国产的放心啊。但是如果反过来功能差，投入还大，只扛了一杆国产的大旗，就想来抢钱，那么用户就接受不了了。毕竟，当年1000个Oracle有1个是付费的吗？既然这个都不给钱，国产做出来的不如Oracle的凭什么给钱？就凭“奉旨”要饭？当然了，技术肯定是要发展的，毕竟当初的Oracle也是一身的毛病。国产需要成长空间，政策本身也是希望促进国产发展。但是，有些厂商钻了国家战略的空子，用迎合政策的手段完成自己商业目的，进行所谓的“奉旨”要饭。为什么呢？因为我们本来的计划是弯道超车，结果这些厂商发现弯道上都是钱，那还超车干什么？捡钱啊！而且从技术上来说，有些时候是没有捷径可走的。直道如果跑不赢，那么弯道一样也不行。但不管直道还是弯道，总要向前走。现在的有些信创厂商是不想向前走，想的是牺牲长期营利，赚奉旨讨饭的钱，一个无法长期营利的企业，行为注定走形，又怎么能提升技术呢。我们可以有自己的数据库，慢慢做。不要急功近利。做到足够好，可以和别人一较上下，而且价格有优势的话，会有机会的。说到这里还有人说，那市场都被别人占有了，不能等来不及了。那我就要说了，早干什么去了？现在已经保护了，没有让国产和非国产去硬碰硬，那都是国产，布局早，质量好的产品就该有更好的市场。也能看到不少人的文章，有的说到数据库替换是换肤还是换心。本来可能很多人都觉得换数据库是两步，把数据导出来，把数据导进去。比把大象放冰箱还少一步。其实那是没意识到数据库是IT系统的心脏。如果说一个人的心脏出问题了，换是自然而然的。但是如果人本身用的好好的，给他换一个一模一样的。这就是无病呻吟。平白无故挨一刀。最要命的是有时候还换了一个不如原来的，那么就是一堆问题了。而实际上就是绝大多数企业在数据库上并没有遇到什么不可调和的问题。运行好好的，现在在这种好好的情况下强制替代。当然这里会有很多人会说将来被制裁的时候，那么就没有服务了。说到这里就好像这些年使用Oracle、MySQL、SQLSERVER等就买过服务一样。Oracle白嫖、MySQL魔改+白嫖、PG魔改+白嫖。没怎么买过商用的产品（其实买以上产品主要是买服务）。MySQL和PG更加不用说了，也没买过服务。SQLSERVER是破解。既然原来没买，那么将来如果退一万步被制裁，买不到，好像没什么区别。有些厂商搞焦虑营销，今天2027了，明天接到命令了。无非是在最后期限到达之前，能让用户多掏钱买就多买一些。因为过了这个村就没这个店了。2027以后如果没替换完会怎么样？可能大概率就不替换了，否则如果2027不行，那就2030。2030不行，就2035。那就无限期，那么既然无限期，也不用着急。慢慢等吧。其实很多时候我们想多了。一个数据库好不好，或者说替换不替换。和数据库从业人员关系不大。一个在使用MySQL的企业，即使说全部换成盗版的Oracle不用花许可，他也不会去换。因为大家都知道，应用程序要大改。更何况现在是把这些换成了一些相对Oracle的成熟来说，还不那么成熟的产品。替换对于大部分DBA是不友好的。这并不是说DBA不愿意学习。而是学习成本高。本来就是一份工作，在哪里都是干。A银行换到B银行，都是DB2或者都是Oracle。现在10个银行可能有10种数据库。这使得换工作的成本高，选择少了很多。而由于原来成熟的数据库的可观测性等完善，容易轻松定位到问题，甚至可以定位到存储或者是网络的问题。而现在很多国产这个没有那个不行。定位问题都困难别说解决问题了。那么这个时候不明真相的人就以为，你这个DBA不行嘛，只会Oracle或者MYSQL嘛。这是人的问题吗？是这个产品不支持啊和我有什么关系！替换对于所有的开发人员来说也是不友好的。本来屎山的代码能混就混，现在不得不重构。问题是当初的雷不好排，现在只能自己硬趟，最后炸的遍体鳞伤。替换数据库中主力是应用开发的重构适配改造。相比较买软硬件来说，那些都是小钱了。改造才是大头。试想十几年做的几乎都要重做一遍，代价有多大？而这些意义有多大？如果说单纯讲安全，那么看看另外一个关乎国家安全的，护网。有些形式主义的公司，每年都是几个月，最后除了让安全厂商赚一笔还有其他什么？遇到问题就是关机和拔网线。等护网过去以后，再开起来。这就安全了？所以用甲骨文的Java连接甲骨文的Oracle和MySQL的。再用甲骨文的Java再写一遍，连接的是有些基于甲骨文的MySQL数据库和基于PG的数据库，就安全了？有些产品生态是没法说了。用PG的理念去处理，发现根本处理不了。因为全重写了。而这个又开枝散叶出去了ABCDE这些分支。可以想想即使会PG的也不一定能解决ABCDE的问题（我说的是不一定不绝对）。而ABCDE在这个上面又做了自己的。当A遇到问题，B分支的人也解决不了A的问题。说白了用户选了这些分支，只能找这些分支的。找源头、找PG都不一定行。这和Oracle、原生的MySQL、原生的PG不一样了。公司找不到人，可以在社会上找，国内找不到可以国际上求助。现在必须找绑定的厂商。自主不自主不知道，可控不可控完全控制在厂商手中了。说着说着还是要说国内还是有做的好的，有些都在DB-engine上有排名了。实打实做出来的。而有些是靠着关系在国内上马的。我从头到尾说的都是这种又贵又不好用的。 「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
