数据蒋堂 | 怎样看待存储过程的移植困难

正文

请到「今天看啥」查看全文

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

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

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

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

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

专栏作者简介

请到「今天看啥」查看全文