用友U9,号称世界级的产品让我失望
|
admin
2011年1月7日 1:10
本文热度 30763
|
使用ERP多年,最近有兴获得学习U9的机会.总体来说这款产品从理念上让人为之一震,感觉真有大产品的架构.本人比较喜欢从技术角度分析问题.拿到产品后发现SOA到底体现在什么地方,如何和第三方产品集成,特别是跨平台的集成.为搞清楚这一问题,深入到数据库中分析,另我吃惊、失望。整个U9产品的核心计算几乎全部通过存储过程实现，包括MRP计算、ATP计算、成本计算甚至密码的加密算法也在存储过程实现。整个系统用了7百多个存储过程，1百多个类似于存储过程的标量函数。也许才学疏浅，这种方法怎么实现SOA。同时系统的性能如何保障、安全性如何保障，以下是部分存储过程或函数的名称。希望和大家交流，大量使用存储过程，对一个大型软件来说是否合适。
FN_ABC_ABCCcompile_GetQty 通过转换率计算数量
fn_BOM_CalcCumYield 工序累计产出率计算
fn_BOM_GetConvertRatio 获得不同单位的转换率
fn_BOM_GetRoundValue 计算数量进行四舍五入
fn_BOM_GetSupplier 获取供应商
fn_CA_GetMoneyRoundValue 获取金额绝对值
fn_CRP_CalcBOMCompQty BOM子件用量计算
fn_CRP_CalcResQty 计算资源用量
fn_CRP_CalcWorkDayByOffsetHours 根据偏移量计算工作日结束时间
fn_CRP_CalItemLeadTime 计算提前期
fn_CRP_GetConvertRatio 获得不同单位转换率
fn_CRP_GetDayCount 计算两个日期之间的工作天数
fn_CRP_GetIntervalWorkDays 取两个日期之间的工作日天数
fn_CRP_GetLeadTime 获得计算后的提前期
fn_CRP_GetRoundValue 获取绝对值
fn_CRP_GetUOMRatio
fn_CRP_GetWorkDate 获得工作日历日期
fn_CRP_GetWorkDate_Hour 获得工作日历小时
fn_CRP_GetWorkDateByOrigCalendar 获得工作日历日期
fn_CRP_GetWorkDay 计算工作天数
fn_CRP_GetWorkDays 计算工作天数
aspnet_Membership_GetPassword
aspnet_Membership_GetPasswordWithFormat
aspnet_Membership_GetUserByEmail
aspnet_Membership_GetUserByName
aspnet_Membership_GetUserByUserId
aspnet_Membership_ResetPassword
该文章在 2011/1/7 1:10:28 编辑过
| |
全部评论32 |
|
admin
2011年1月7日 1:11
请教楼主：SOA不是指软件之间的协同么？同一个软件也存在这个问题么？
该评论在 2011/1/7 1:11:00 编辑过
|
|
admin
2011年1月7日 1:11
用存储过程很正确呀.
SOA==>这东西我不了解,但我知道,( 这种名词,是用来哄人的,楼主别太在意, 真正的: 谁能写好好程序,谁就是NO1)
存储过程:可以大大提高运算性能, 并且让逻辑更加灵活.
(你想一下,不同客户,只要改改存储过程即可,无需涉及到"应用程序"这一层)
并且,楼主不知道,存储过程也可以欠套.是一个非常好的东西.(代码可以避免重复).
(我是搞开发的)
至于用友U9,我就从没用过.不敢评论. *_*
该评论在 2011/1/7 1:11:39 编辑过
|
|
admin
2011年1月7日 1:12
纯粹的SOA不提倡用存储过程/函数,把数据库只视为一个存储数据的地点,所有的业务逻辑都不在数据库中实现,在应用服务器中实现业务逻辑.从这个角度讲U9肯定不是严格的SOA构架.但是,实际使用中,纯粹的SOA构架效率存在问题,需要频繁的读写数据,对硬件要求也高(我们的一个ERP,采用类似构架,用了4台小型机做应用服务器,oracle数据库unix操作系统).要解决这个问题,需要打破这个模式,折中的办法是限制存储过程的使用,别烂用.这又需要仔细的系统设计,用友,显然不具备这种精雕细作出精品的精神
该评论在 2011/1/7 1:12:16 编辑过
|
|
admin
2011年1月7日 1:12
纯粹的SOA不提倡用存储过程/函数,把数据库只视为一个存储数据的地点,所有的业务逻辑都不在数据库中实现,在应用服务器中实现业务逻辑
-->这种框架有优点,也有缺点: 开发成本高,程序执行效率低.
写完后,才发现楼上也讲到这一点.
该评论在 2011/1/7 1:12:36 编辑过
|
|
admin
2011年1月7日 1:12
存储过程不是好东西,但程序员都爱用,呵呵
该评论在 2011/1/7 1:12:48 编辑过
|
|
admin
2011年1月7日 1:13
开发成本还好了,没听说过有模板这个东西吗?有积累的软件开发机构都有模板,固定的套路,设计做好了,规范执行严格,软件工程成熟,真是高中生也可做程序员
该评论在 2011/1/7 1:13:13 编辑过
|
|
admin
2011年1月7日 1:13
QUOTE:
--------------------------------------------------------------------------------
原帖由 alone1998 于 2009-6-26 13:07 发表
存储过程不是好东西,但程序员都爱用,呵呵
--------------------------------------------------------------------------------
如果你打算支持多种数据库,那就要用"应用服务器"这个东西,(在这里,可以用标准SQL来写)
如果只打算支持一个数据库,那还是建议用存储过程, 可以成倍地提高的数据运算效率和准确值.
(这里说一下准确值问题: 由于开发工具与数据库对浮点运算解决方法不同,在大运算中,常会出现二者计算结果不符的现象,
这里你就要以一个为标准)
该评论在 2011/1/7 1:13:47 编辑过
|
|
admin
2011年1月7日 1:14
QUOTE:
--------------------------------------------------------------------------------
原帖由 OKRA-ERP 于 2009-6-26 13:21 发表
晕了，我在我研究学习的那个ERP中，怎么就没有存储过程这个概念，甚至连关系和视图也没。打开数据库表，除掉一张张单独的表单外，什么都没有。
--------------------------------------------------------------------------------
这说明你这款软件支持多种数据库哟.
(不知是福还是祸)
该评论在 2011/1/7 1:14:09 编辑过
|
|
admin
2011年1月7日 1:15
谢谢大家的反馈,我也在学习中.
众所周知，小型软件因为逻辑简单、数据量小，选择什么数据库，采取什么技术架构等无关紧要，都能达到目标，尽可能简单、经济。
而大型软件，特别是号称和SAP叫板的U9采取这样的技术就有点外行了。
大型软件至少要包含三层，数据库层：主要负责存储，要求有较高的吞吐量；业务逻辑层，也叫中间层：主要负责核心业务处理，如校验、检查、计算等，要求安全、可靠；最靠近用户一层主要用来展现界面，要求表现力丰富，易用、易学。
现在U9把中间层要做的事情都让数据库服务器代劳。显然对数据库服务器带来成本的压力，同时该系统存储过程都是开放的，任何人都可以随意修改，对系统的稳定性和安全性带来隐患。
同时，如果通过存储过程来实现如MRP计算，如果计算量很大的情况下势必会造成服务器的资源耗尽，一旦进行MRP计算，所有人都无法工作了。并且，这种计算在前端是无法知道进度的，象死机一样，当然也无法知道什么时候能够结束。
大量的计算也回带来死锁，乃至瘫痪。
根据我以往的经验，并发数超过100就很困难了，不可靠了（丢数据、死机等）。要达到200，购买最好的服务器恐怕也困难。
该评论在 2011/1/7 1:15:10 编辑过
|
|
admin
2011年1月7日 1:15
准备支持多数库的，就不能用存储过程。
只支持单一数据库的，可以使用存储过程来提高算法的效率。
存储过程和SOA并没有任何关系。SOA讲究的是服务的封装，标准的SOA中你是无法绕过一个服务去调数据库底层的。
存储过程是被服务封装起来了的。
至于说被人修改什么的，根本不是问题。任何一个数据库存有权限机制，为何不用？
看来楼主似乎也是一知半解呀。过滤掉漫骂攻击的贴子，在这个论坛还是可以学到一些东西的。
该评论在 2011/1/7 1:15:42 编辑过
|
|
|
400 186 1886
