数据蒋堂 | 怎样看待存储过程的移植困难
来源：数据蒋堂
作者：蒋步星
本文长度为1168字，建议阅读4分钟
本文通过剖析数据库的现状，探查怎样看待存储过程的移植困难问题。
存储过程移植困难是经常被诟病的，在罗列存储过程的缺点时，这一条几乎从来不会被遗漏。
存储过程的移植确实很困难，一般业务逻辑复杂到需要写存储过程的地步，总会不可避免地用到数据库独有的特性和语法，更换数据库时这部分代码就需要重写。如果只是简单地替换函数名和参数规则（如日期转换等），那成本还不高；如果用到了新数据库不支持的某种特性（如窗口函数），那还要重新设计算法来编写计算逻辑；如果还要再兼顾性能因素，有时候就会是个不可能完成的任务了。
不过，还好，存储过程移植的情况并不频繁。
多年前数据库市场还处于混战阶段时，用户更换数据库是相对常见的事情。而如今，传统关系数据库市场的竞争已经趋于稳定，各个行业和业务采用的数据库已经基本定型。更换数据库并不只是存储过程移植这么一件事，用户从使用习惯到维护人员配备等各方面都要做出很深刻的改变，这是个成本巨大的工程。如果没有重大事件，一般不会发生数据库移植的事件。存储过程移植虽然困难，但并不足以成为不采用它的重要理由。
至于需要面对各种行业不同用户的通用BI类软件，虽然经常要接入不同的数据库，但很少会用到存储过程，只是些SQL函数更换，就没有难度了。
其实，仔细研究一下会发现。存储过程的移植困难主要发生于从商用数据库到开源数据库（包括一些近年来兴起的一些基于大数据平台的数据仓库）的切换过程。同价位的商用数据库之间的移植难度并不是很大，而从开源数据库到商用数据库则更是容易（虽然这种现象发生较少）。
如前所述，存储过程在数据库之间的移植难度，语法不同只是个载体，更深层次的原因在于各个数据库的功能特性不同。同价位的商用数据库，其功能相差并不大，移植时主要就是更换语法，难度就不会很大。而开源数据库在功能方面和成熟的商用数据库相差很远，虽然大家都叫数据库，都能跑基本SQL，但差别是巨大的，从许多关键的特性上看根本就是两个不同的产品。比如世界上最著名的那个商用数据库，对SQL2003的标准支持得很好，有较完整的窗口函数；而世界上那个最著名的那个开源数据库，别说窗口函数，连FULL JOIN都要转换成UNION来做。这时候想移植存储过程，那就是相当于完全重新开发。这个困难根本就不是移植造成的，如果当初选择开源数据库建设应用，那困难一样的大。
我们说移植成本，是指基于两个能力基本相当的平台，最初的开发工作无论基于哪个平台，复杂度是差不太多的。比如一段C++程序，在Windows上写和在Linux上写，难度区别并不大，这时候讨论移植工作量才有意义；但要把一段Java程序转换成C++程序，这就不是个移植问题了，初始的开发复杂度就相差巨大。从商用数据库到开源数据库的迁移大抵类似于这种。
目前，从商用数据库切换到开源数据库或大数据平台是一个业内趋势，这样做在数据库建设成本上会下降许多。不过这个世界是公平的，购置数据库的成本下降了，而这并不是技术进步带来的结果，那就从开发成本上补回来吧。
专栏作者简介
润乾软件创始人、首席科学家
清华大学计算机硕士，著有《非线性报表模型原理》等，1989年，中国首个国际奥林匹克数学竞赛团体冠军成员，个人金牌；2000年，创立润乾公司；2004年，首次在润乾报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准；2014年，经过7年开发，润乾软件发布不依赖关系代数模型的计算引擎——集算器，有效地提高了复杂结构化大数据计算的开发和运算效率；2015年，润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”；2016年，荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业十大领军人物”；2017年, 自主创新研发新一代的数据仓库、云数据库等产品即将面世。
数据蒋堂
《数据蒋堂》的作者蒋步星，从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞，虚拟与现实的相互交织，产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点，站在研发人员的角度从浅入深，进行全方位、360度无死角深度剖析；对于一些业内观点，站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展，站在业内专家角度给予预测和推断。静下心来认真研读你会发现，《数据蒋堂》的文章，有的会让用户避免重复前人走过的弯路，有的会让攻城狮面对扎心的难题茅塞顿开，有的会为初入行业的读者提供一把开启数据世界的钥匙，有的甚至会让业内专家大跌眼镜，产生思想交锋。
往期回顾：