第13期:怎样看待存储过程的移植困难

企业动态
存储过程的移植困难主要发生于从商用数据库到开源数据库(包括一些近年来兴起的一些基于大数据平台的数据仓库)的切换过程。同价位的商用数据库之间的移植难度并不是很大,而从开源数据库到商用数据库则更是容易(虽然这种现象发生较少)。

第13期:怎样看待存储过程的移植困难

存储过程移植困难是经常被诟病的,在罗列存储过程的缺点时,这一条几乎从来不会被遗漏。

存储过程的移植确实很困难,一般业务逻辑复杂到需要写存储过程的地步,总会不可避免地用到数据库独有的特性和语法,更换数据库时这部分代码就需要重写。如果只是简单地替换函数名和参数规则(如日期转换等),那成本还不高;如果用到了新数据库不支持的某种特性(如窗口函数),那还要重新设计算法来编写计算逻辑;如果还要再兼顾性能因素,有时候就会是个不可能完成的任务了。

不过,还好,存储过程移植的情况并不频繁。

多年前数据库市场还处于混战阶段时,用户更换数据库是相对常见的事情。而如今,传统关系数据库市场的竞争已经趋于稳定,各个行业和业务采用的数据库已经基本定型。更换数据库并不只是存储过程移植这么一件事,用户从使用习惯到维护人员配备等各方面都要做出很深刻的改变,这是个成本巨大的工程。如果没有重大事件,一般不会发生数据库移植的事件。存储过程移植虽然困难,但并不足以成为不采用它的重要理由。

至于需要面对各种行业不同用户的通用BI类软件,虽然经常要接入不同的数据库,但很少会用到存储过程,只是些SQL函数更换,就没有难度了。

其实,仔细研究一下会发现。存储过程的移植困难主要发生于从商用数据库到开源数据库(包括一些近年来兴起的一些基于大数据平台的数据仓库)的切换过程。同价位的商用数据库之间的移植难度并不是很大,而从开源数据库到商用数据库则更是容易(虽然这种现象发生较少)。

如前所述,存储过程在数据库之间的移植难度,语法不同只是个载体,更深层次的原因在于各个数据库的功能特性不同。同价位的商用数据库,其功能相差并不大,移植时主要就是更换语法,难度就不会很大。而开源数据库在功能方面和成熟的商用数据库相差很远,虽然大家都叫数据库,都能跑基本SQL,但差别是巨大的,从许多关键的特性上看根本就是两个不同的产品。比如世界上***的那个商用数据库,对SQL2003的标准支持得很好,有较完整的窗口函数;而世界上那个***的那个开源数据库,别说窗口函数,连FULL JOIN都要转换成UNION来做。这时候想移植存储过程,那就是相当于完全重新开发。这个困难根本就不是移植造成的,如果当初选择开源数据库建设应用,那困难一样的大。

我们说移植成本,是指基于两个能力基本相当的平台,最初的开发工作无论基于哪个平台,复杂度是差不太多的。比如一段C++程序,在Windows上写和在Linux上写,难度区别并不大,这时候讨论移植工作量才有意义;但要把一段Java程序转换成C++程序,这就不是个移植问题了,初始的开发复杂度就相差巨大。从商用数据库到开源数据库的迁移大抵类似于这种。

目前,从商用数据库切换到开源数据库或大数据平台是一个业内趋势,这样做在数据库建设成本上会下降许多。不过这个世界是公平的,购置数据库的成本下降了,而这并不是技术进步带来的结果,那就从开发成本上找补回来吧。

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2017-06-23 14:40:29

存储数据库逻辑分离

2017-08-02 17:00:51

SQL关系代数数据

2013-01-21 13:41:59

IBMdW

2017-05-24 17:08:29

OLAP

2011-10-14 18:38:51

Linux运维趋势优化电子杂志

2021-04-12 14:15:57

技术资讯

2017-06-11 13:27:18

列式存储数据

2011-06-20 09:58:17

Qt Qtopia 移植

2011-07-14 09:15:35

云计算大话IT云计算市场

2011-09-06 14:59:32

开发技术周刊

2012-09-24 09:31:28

应用移植性云计算云平台应用程序

2010-04-12 11:37:57

Oracle RAC

2009-07-03 14:31:51

云计算云存储

2011-06-03 10:31:14

SQL

2015-01-05 10:43:04

IT技术周刊

2017-04-26 07:50:14

机器人

2021-11-18 14:57:53

大数据运营商网络

2023-11-07 07:21:04

2013-07-24 11:46:47

网络·安全技术周刊

2010-07-15 12:38:14

SQL Server存
点赞
收藏

51CTO技术栈公众号