【IT168 技术分析评论】
近日，ITPUB社区ERP板块，一位使用ERP多年的网友李新(化名)在学习使用U9的过程中，发帖抱怨U9中使用了大量的存储过程，并质疑号称全球先进款基于SOA架构的ERP系统U9，其SOA设计架构理念到底体现在哪些地方?
该社区的信息化相关板块，聚集了国内大部分ERP实施顾问，讨论产品线涵盖国内外主流的ERP产品和技术。李新的帖子发布后，立刻在ITPUB社区引发了轩然大波，多达上百位从事ERP顾问和选型，及实施的技术网友参加了讨论，发表自己的见解。
图：用友U9产品SOA理念和架构遭质疑
用友ERP 存储过程滥用?
记者调查了解到，整个U9产品的核心计算的确几乎全部通过存储过程实现，包括MRP计算、ATP计算、成本计算甚至密码的加密算法也在存储过程实现。整个系统用了7百多个存储过程，1百多个类似于存储过程的标量函数。
网友alone1998认为，“纯粹的SOA不提倡用存储过程/函数,把数据库只视为一个存储数据的地点。所有的业务逻辑都不在数据库中实现,在应用服务器中实现业务逻辑。从这个角度讲 U9肯定不是严格的SOA构架。但是,实际使用中,纯粹的SOA构架效率存在问题,需要频繁的读写数据,对硬件要求也高(我们的一个ERP,采用类似构 架,用了4台小型机做应用服务器,oracle数据库unix操作系统).要解决这个问题,需要打破这个模式,折中的办法是限制存储过程的使用,别烂用。这又需要仔细的系统设计,用友是否这样做的了不得而知。”
记者就此采访其它技术人员时，但他们表达了相反的观点，认为SOA的设计理念和是否大量使用存储过程没有直接关系。
“其它的ERP产品如Oracle EBS同样大量使用了存储过程。用这一点来指责和质疑SOA的设计理念和研发的技术实力，立足点完全错误!至于说，有些业务逻辑计算是否一定要放在后台，通过存储过程来实现，这一点是可以讨论的。”一位从事多年ERP实施的技术顾问接受采访时表示。
ERP系统涉及大量的业务逻辑处理和计算，将这些业务逻辑处理计算动作全部放在后台数据库实现，的确看上去有悖分层设计架构的思想。分层开发设计的思想是，业务逻辑计算尽量封装在业务逻辑层，而不是将其全部下压到数据库层面来实现。
“业务逻辑处理和计算，如果直接用存储过程实现，不利于复用，也不利于数据库的跨平台移植(因为大部分数据库系统的SQL标准实现是有差别的，在一个DBMS中能够正常运行的存储过程，放到另一个平台几乎全部要重写);我们在做项目时，如果有开发人员这么做，被视为是偷懒的表现。”一个从事CRM系统开发的项目主管小李认为。
据记者了解，还有批评者认为，现在U9把中间层要做的事情都让数据库服务器代劳，显然对数据库服务器带来成本的压力。另外，安全性也是一个问题，因为系统存储过程一般都是开放的，任何人都可以随意修改，对系统的稳定性和安全性带来隐患。
“如果通过存储过程来实现如MRP计算，如果计算量很大的情况下势必会造成服务器的资源耗尽，一旦进行MRP计算，所有人都无法工作了。并且，这种计算资源消耗在前端是无法知道进度的，象死机一样，当然也无法知道什么时候能够结束。大量的计算也回带来死锁，乃至瘫痪。根据我以往的经验，并发数超过100就很困难了，不可靠了(丢数据、死机等)。要达到200，购买最好的服务器恐怕也困难。”一位有着数据库管理经验的ERP技术实施顾问这样认为。
对此，EBU平台开发部经理张劲涛的解释认为，ERP软件需要处理大量业务数据，核心计算通过数据库存储过程来实现，一方面是为了减少网络数据流量，提高数据处理效率;另一方面在数据库层面进行事务处理和控制比在应用程序中使用分布式事务更高效、占用的资源更少;还有一个就是灵活性问题，设计良好的存储过程，当业务逻辑或规则发生变化时，可以不用修改软件代码，只需修改存储过程即可，这对于用户和软件开发商来讲，可以降低维护成本和升级花费;另外，扩展开来还有一个系统健壮性和安全性问题，在非电信级商业网络环境中(比如：大多数企业局域网)，尽量减少设备节点和层次意味着更高的可靠性，尽量减少数据在网络上暴露和传输的机会意味着更高的安全性。
另外，他也承认使用存储过程有可能使得系统存在缺陷。“存储过程的一个缺陷是对于非数据密集型运算其实是很低效的，可能会过多的占用DB Server的CPU资源，而使得性能强大的Application Server的计算能力被闲置;另外，对于强调协作的分布式应用来，计算能力的过于集中在一定程度上降低了灵活性，毕竟现在早已不是大型主机的时代。”
最后他认为U9产品中大量使用存储过程是一个比较合适的做法，并无不对。“对于商业软件来讲，核心计算是否选择存储过程实现不能一概而论，要根据具体应用的特点和性能要求综合考虑，在此过程中可靠性和有效性往往会起很大的作用。”
