这个题目有点拗口,和最近有些话题有点关系,但是更多的还是我作为这些年过来的一些矛盾的阐述。
从前有个笑话。一队军舰在水域巡航,这天晚上大雾。军舰看看到前方有灯光,立刻发出“海军灯语”。请立即让开。对方也给这艘军舰发出灯语,请你绕开。军舰不服,打出灯语:“我是旗舰,你必须要让我先通过。”对只回应说:“你让开,我是灯塔。我在这里已经很久了,我为所有的船只提供导航服务。没有我,很多船只都会撞到礁石上。”这个笑话利用了“旗舰”和“灯塔”这两个词的双关含义。在海军中,“旗舰”是指一艘指挥舰,所有军舰要服从我,而在航海中,“灯塔”是一种为船只提供导航指示的人工光源。因此,这个笑话的幽默之处在于军舰和灯塔都认为自己的地位更重要,不愿意让对方先通过。
工作过一些公司和行业。有些公司是意识到应用开发(这里指后端的)是几乎全部围绕着数据库展开的。这里的数据库泛指关系型数据库和NoSQL等数据库。(很多人不把Redis、ELasticSearch、MongoDB等当做数据库,不知道谁给灌输的概念。可悲)。
也有一些公司从上到下没有意识到这一点,领导觉得数据库不重要,开发最重要。其实不少都是框架完成的,有些变量都是抄来的改一改,甚至改都不改拿来就用。我有时候做一些演示的时候就利用了这种方式。我也是通过这种学习发现后端程序中50%以上,甚至应用程序中80%是SQL。可以说主体是SQL。
也有一些公司开发人员觉得自己最大。面向对象编程而不是面向数据库编程,数据库应该围绕着对象来。
凡是都是从不同角度出发,在我的角度我觉得我是对的。站在开发人员和领导层面觉得他们的认知中他们是对的。那么只能讲几个事情来看看了。
事件1:在工作中引入专业的数据库建模工具。在数据库标准制定和建模过程中,发现模型分为业务模型、逻辑模型和物理模型。而这一切与面向对象编程不冲突。业务从需求设计开始就是要确定好,最终是通过逻辑模型映射到物理模型上(即数据库表和字段)。也就是说即使面向对象编程还是以数据库为核心的。
事件2:某公司国产化要求。第三方服务商对数据库迁移的项目报价,预计成本几十万(在100万以内),随后应用开发方报价(应用程序改写)成本几千万(一亿以内)。从这个上面来说,数据迁移好做,应用改写难做。用现在一句话说叫国产适配改造。从这句话上就可以看出,是应用程序去适配数据库,不是数据库来适配应用程序。
事件3:说到数据库兼容性。前几天有文章说兼容Oracle程度比较高的是达梦和OceanBase。可能从这个角度是数据库适配应用。因为出发点是说最好应用程序不改变,而完成了替换。可能有人会说这就是数据库适配应用。确实表面上是的。这种兼容的特点就是原来应用程序(中的SQL)在新的数据库上不报错。这就是兼容性。那么这里请思考一个这样的问题,那就是SQL不报错了。那么性能是不是一模一样。这时候几乎所有的人都回答我说,怎么可能还是不一样的。那么问题来了,语法不报错。为了性能可能要做一些SQL改写(能改写好的算运气好的了),那这个改写的算不算对新数据库的适配改造呢?我觉得算。运气不好的那就大改特改了,甚至是重构。网上有一篇文章,是陆金所去O的。从2015年开始说了好几年。大家可以去网上查原文。说她们用MySQL替代(尽管不少业内人说用MySQL去替代Oracle,能叫替换吗?这两个是一家啊)。替换完成后85%的场景都是改为单表查询。也就是说深度面向对象了,而且也结合新的数据库全面适配了。花了好几年,钱花了也不少。这个在网上都能查得到。感兴趣的自己去查。 对于一般的传统企业来说如果也这样,那么当初信息化建设花了多少钱,现在就要再花一次。而且可能花的还要多。因为5年前的人工和现在的人工不一样了。我就估算我司要是全重做一遍怎么也要上亿的开发人工投入。
事件4:一般的数据库单表都不是问题。越多关联可能就不行。做数据库的都知道和优化器、执行器等等都有关。那么基于陆金所那种改造,从逻辑模型和物理模型都彻底推翻的重构,已经不能用伤筋动骨来说了,就是涅槃重生。那么诸位都知道让开发优化SQL势比登天的日常工作来说,让开发人员把祖 传代码重第一行开始写起来,不亚于杀人父母了。这种时候面对几百上千的开发,能不能顶得住?关键这个时候还居然要考核你稳定性。如果不考核稳定性,就不会这么矛盾。开发不改了,宕机就宕机。矛盾就没有了。替换就容易多了。
通过以上我觉得我说明白了是谁适配谁。在我这个角度而言数据库是“灯塔”,无论那种数据库都是。
数据库本身是数学和物理学的结合。你看看优化器和统计信息就知道了。肉眼可见的统计学本身就是数学的一个分支,优化器的算法不太可见。而CPU磁盘这些都是基础物理的范畴,当然数据库还涉及到网络。对了分布式数据库的raft和Paoxs也是算法。说这么多,不重视的还是不重视。觉得切换一个数据库过来就是数据导出导入的也是大有人在。只要不要稳定性,怎么来都行啊,DBA们是没有太大问题的。多学一个数据库体系而已。只要不要稳定性,怎么来都行,开发人员只要不让他把自己和前几任写的代码都重新写一遍也没有多大的问题的。
但是数据库"灯塔"的存在不是以人的主观为转移的。要不?撞一下试试?